Hallo, eine kurze Frage zu dem Artikel: Globale Variablen Zitat: >Das extern bewirkt, dass für Global1 jetzt keine Variable >mehr erzeugt wird. Es ist nur noch die Information, >daß es irgendwo eine Variable namens Global1 gibt >und das diese vom Typ int ist. >Soweit so gut. Aber irgendwo muss diese Variable >auch tatsächlich existieren, sonst könnte der Linker >sie nicht finden, wenn er alle Einzelteile zu einem >kompletten Programm zusammenbaut. Alle einzelnen *.c Dateien >referenzieren sich ja nur noch auf eine Variable, die irgendwo >anders erzeugt wird. *Nur wo?* *Nur wo?* Gibt es eine Festlegung, dass die Definition einer Variablen immer im main.c zu liegen hat, oder kann diese auch in irgendeiner anderen C-Datei liegen? Gerade wenn man viele Daten-structs anlegen möchte, wäre es meiner Meinung nach sinnvoller, diese in einer Datei global.c anzulegen, anstatt alles vor der eigentlichen main-Funktion zu erledigen... mfg
Nein, es gibt keine Festlegung. Du kannst solche globalen Variablen selbstverständlich in eine eigene Datei packen ... finde ich übrigens auch viel aufgeräumter so ... Viel Spaß beim Programmieren.
Noch schöner ist es natürlich, auf globale Variablen ganz zu verzichten, wo immer es geht. Oliver
Servus, globale Variablen lieber nicht benutzen, besser static Variable benutzen und eine get-Funktion schreiben. So ist klar definiert das die Variable immer geholt und nie geschrieben wird. Beste Grüße public
Bitte nicht "int i" global definieren! :-) Ich habe schon ein Programm gesehen, bei dem "int i" global definiert war und andere *.c Files mit "extern int i" auf diese Variable zugegriffen haben. Man glaubt es kaum...
public schrieb: > So ist klar definiert das die Variable immer geholt und nie geschrieben > wird. Wenn sie aber nie geschrieben wird, dann ist es keine Variable, sondern eine Konstante :-)
R2D2 schrieb: > public schrieb: >> So ist klar definiert das die Variable immer geholt und nie geschrieben >> wird. > > Wenn sie aber nie geschrieben wird, dann ist es keine Variable, sondern > eine Konstante :-) naja, gemeint war wohl "versehentlich" geschrieben wird
Daniel V. schrieb: >> public schrieb: >>> So ist klar definiert das die Variable immer geholt und nie geschrieben >>> wird. >> >> Wenn sie aber nie geschrieben wird, dann ist es keine Variable, sondern >> eine Konstante :-) > > naja, gemeint war wohl "versehentlich" geschrieben wird War schon klar :-) Übrigens finde ich oft genug Code durchaus übersichtlicher, wenn Variablen global definiert werden, anstatt immer über Funktionen oder andere Hilfskonstrukte darauf zuzugreifen. Wenn eine Variable einen globalen Charakter hat, dann finde ich es nur konsequent, sie auch als global zu deklarieren. Nette Kommentare im Sourcecode tragen übrigens auch sehr zum Verständnis bei :-) Just my 2 cents
Oliver schrieb: > Noch schöner ist es natürlich, auf globale Variablen ganz zu verzichten, > wo immer es geht. Das ist völliger Quatsch, besonders im Embedded Bereich. Es gibt keinen logischen Grund, warum für einen Temperaturregler die Temperatur nicht global sein soll. Gruss Reinhard
Reinhard Kern schrieb: > Oliver schrieb: >> Noch schöner ist es natürlich, auf globale Variablen ganz zu verzichten, >> wo immer es geht. > > Das ist völliger Quatsch, Nun ja, man beachte den zweiten Halbsatz. Es gibt selten ein richtig oder falsch, wenn globale Variablen sinnvoll sind, warum nicht. Es gibt aber durchaus Kontruktionen, die einem irgendwann auf die Füsse fallen. Und zwar garantiert. Oliver
Oliver schrieb: > Es gibt aber durchaus Kontruktionen, die einem irgendwann auf die Füsse > fallen. Und zwar garantiert. Ja, zum Beispiel wenn man wegen solcher falschen Ratschläge alle Variablen mit mit new oder malloc erzeugt und mit Pointern auf sie zugreift - zwar cooler C-Stil, öffnet aber riesige Fehlermöglichkeiten, die völlig überflüssig sind. Gruss Reinhard
public schrieb: > So ist klar definiert das die Variable immer geholt und nie geschrieben > wird. ... ausser jemand käme auf die Idee eine Set-Funktion zu schreiben!
Reinhard Kern schrieb: > Das ist völliger Quatsch, besonders im Embedded Bereich. Es gibt keinen > logischen Grund, warum für einen Temperaturregler die Temperatur nicht > global sein soll. Mir erschliesst sich nicht, was das jetzt mit Temperaturregler/Temperatur zu tun haben soll. "Logische" Gründe gibt es durchaus einige, z.B. zum einen der Kapselungsgedanke. Zum Anderen: Log mal deine Temperatur, wenn jeder, der Lust hat, direkt die Variable manipuliert. Ich bin übrigens auch in der Embedded Ecke unterwegs und das nicht erst seit gestern. Auch in diesem Bereich ist durchaus ordentliche SW Architektur bzw. Design möglich!
Servus zusammen, get- und set-Funktionen müssen natürlich konsequent für jede Variable geschrieben werden die in anderen *.c Files Verwendung finden. Sonst kann es, wie schon andere geschrieben haben, zu massig Seiteneffekten kommen. Kaspelung ist DAS Stichwort. Zudem externe Variablen jedesmal neu deklariert werden müssen, Änderungen an den Variablennamen sind dann auch nicht mehr zulässig oder Enden in langen Abenden. Die entsprechenden get- und set-Funktionen werden genau einmal geschrieben und können beliebig aufgerufen werden. Für Konstanten würde ich eher ein Makro schreiben, aber dadrüber lässt sich natürlich auch diskutieren. Wer es esotherisch mag, sollte globale Variablen benutzen :-) Beste Grüße public
na da habe ich ja eine Diskussion losgetreten... Also ehrlich gesagt erschließt sich mir die generelle Angst vor globalen Variablen nicht. Sobald die Namen eine einigermaßen eindeutige Bezeichnung besitzen und aus mehr als 5 Buchstaben bestehen, ist es doch fast ausgeschlossen, dass es zu unerwünschten Manipulationen kommt. Im embedded-Bereich läuft auf einem Controller doch eh nur eine Software... Da habe ich übrigens gleich eine Anschlussfrage: Wenn ich (auf einem PC) zwei separate Programmprozesse habe, die über einen Scheduler sequenziell in Zeitschlitzen ablaufen, können gleiche globale Variablennamen dann über die jeweiligen main.c - Grenzen hinweg von dem jeweils anderen Programm verändert werden, oder bleiben globale Variablen innerhalb eines Programms begrenzt.
global schrieb: > Wenn ich (auf einem PC) zwei separate Programmprozesse habe, was sind Programmprozesse? 2 Exe Dateien - also 2 Prozesse? > von dem jeweils anderen Programm verändert werden, oder bleiben globale > Variablen innerhalb eines Programms begrenzt. jedes Programm bzw jeder Process hat seinen eigenen speicher. Dies kann man zwar mit linker optionen z.b bei DLLs anpassen aber das ist nicht der normalfall.
Kurze Frage: Reden wir von Programmen die aus 2-3 *.c Files reden oder eher 10-20 oder mehr?? Besten Gruß public
global schrieb: > na da habe ich ja eine Diskussion losgetreten... > > Also ehrlich gesagt erschließt sich mir die generelle Angst vor globalen > Variablen nicht. > Sobald die Namen eine einigermaßen eindeutige Bezeichnung besitzen und > aus mehr als 5 Buchstaben bestehen, ist es doch fast ausgeschlossen, > dass es zu unerwünschten Manipulationen kommt. Die Erfahrung der letzten 50 Jahre bei hinreichend großen Programmen sagt aber etwas anderes. Was bei einem Programm mit 200 Zeilen Code noch funktioniert, funktioniert bei 200-tausend Zeilen Code, 500 Funktionen und Aufrufhierarchien, die sich über 7, 8 Schachtelstufen hinziehen nicht mehr. Da dann noch zu überblicken, welcher Code wann welche globale Variable manipuliert, das entwickelt sich ganz schnell zu einem Albtraum. Das Zauberwort heißt dann 'Modulkapselung'. Ein Modul ist dafür zuständig, die Variablen zu verwalten. Dann hat man auch eine gemeinsame Anlaufstelle um im Debugger die Stellen zu finden, an denen sich der Status des Moduls verändert. Was in einer kleinen Autowerkstatt mit 3 Angestellten funktioniert - jeder nimmt sich einfach das Werkzeug das er gerade braucht - funktioniert in Grossbetrieben nicht mehr. Da gibt es dann eine Werkzeugausgabe, die das Werkzeuglager kapselt und verwaltet. In der Programmierung findet das ganze Konzept der objektorientierten Programmierung einen wesentlichen Grundpfeiler genau in dieser Problematik: Das Programme schneller in ihrer Komplexität mit der Größe wachsen als die Fähigkeiten der Programmierer das Gesamtsystem noch zu überblicken. > Im embedded-Bereich läuft auf einem Controller doch eh nur eine > Software... Im Embedded Bereich macht man auf den kleinen AVR globale Variablen unter anderem auch deswegen, damit man eine aussagekräftige Speicherstatistik bekommt und abschätzen kann, in wie weit das SRAM ausgelastet ist.
static schrieb: > Log mal deine Temperatur, wenn jeder, > der Lust hat, direkt die Variable manipuliert. Karl Heinz Buchegger schrieb: > Was bei einem Programm mit 200 Zeilen Code noch > funktioniert, funktioniert bei 200-tausend Zeilen Code, 500 Funktionen > und Aufrufhierarchien, die sich über 7, 8 Schachtelstufen hinziehen > nicht mehr. Eben, das ist der Unterschied. Wer um alles soll denn bei einem Temperaturregler für ein Aquarium die Temperatur manipulieren, wie von static befürchtet - die Fische? Und wieso soll sie eine nicht globale Variable davon abhalten, wenn man ihnen das schon zutraut? Gruss Reinhard
Reinhard Kern schrieb: > Eben, das ist der Unterschied. Wer um alles soll denn bei einem > Temperaturregler für ein Aquarium die Temperatur manipulieren, wie von > static befürchtet - die Fische? Und wieso soll sie eine nicht globale > Variable davon abhalten, wenn man ihnen das schon zutraut? Wie so oft gilt: "One size fits all" funktioniert bei Baseballkappen, aber das wars dann auch schon. Allgemeine Regeln und Aussagen ala "Das ist völliger Quatsch" sind nun mal problematisch. Auch wenn der Zusatz "besonders im Embedded Bereich" dann doch noch kommt.
Karl Heinz Buchegger schrieb: > Wie so oft gilt: "One size fits all" funktioniert bei Baseballkappen, > aber das wars dann auch schon. Und eben deshalb ist die hier immer wieder anzutreffende Aussage, man dürfe NIEMALS eine globale Variable verwenden, völliger Quatsch. Q.e.d. Die von dir erwähnten 200000 Zeilen Code sind bei Embedded Controllern bisher eher nicht die Regel. Das Forum heisst doch Microcontroller, oder hat sich da was geändert Richtung Supercomputer? Ich glaube, den Leuten, die hier mit Problemen ankommen, dass ihre LEDs nicht blinken, nützt es nur wenig, wenn man ihnen ständig erklärt, wie sie mit einem Team von 500 Programmierern ein Office-Paket entwickeln (überhaupt solltet Ihr das besser mal Microsoft klarmachen). Und ich sehe auch nicht ein, wieso ich eine Messschaltung für Lichtstärken oder pH-Werte unbedingt der reinen Lehre wegen multiuser- und multitaskingfähig machen muss. Schon mal was von KISS gehört? Das trägt mehr zur Fehlerfreiheit bei als alles Gequatsche über angeblich moderne Software-Managment-Methoden auf simplen Controllern für eine bestimmten, begrenzten Zweck. Demnächst wird wohl den Anfängern erklärt, ein LED-Lauflicht müsste unbedingt als zertifizierter Managed Code mit .NET-Laufzeitumgebung entwickelt werden. Gruss Reinhard
Also globale Variable immer, selten, nie, nicht, manchmal, wenn's gar nicht anders geht und bequemer ist, verwenden. Als Name nicht "i" sondern möglichst "Jott" verwenden. ... sämtliche Klarheiten beseitigt! Kapseln, ist das das was man seit neuestem in die Kaffeemaschine schiebt?
amateur schrieb: > ... sämtliche Klarheiten beseitigt! Mit der einen Lehre kommt man halt in der Praxis nicht sehr weit. Ich hatte vor vielen Jahren schon einen Compiler mit strikter Objektorientierung - ein Bit war da ein Objekt mit Konstruktor, Destruktor, Setter und Getter- methoden und überladenenen Operatoren für Oder, Und usw., also ein richtiger Theorie-Traum. Aber völlig ungeeignet um einen 8051 zu programmieren. Gruss Reinhard
Servus zusammen, die Diskussion ist entartet, oder? @Reinhard: 200000 Zeilen Code müssen kein Officepaket sein. Auch Mikrocontrolleranwendungen wachsen schnell in eine schwindelerregend hohe Codezeilenanzahl und dann zählt die Organisation des Codes. GV können hier sehr viel Schaden anrichten und den Code zusätzlich undurchsichtig machen. Ich gebe dir natürlich recht, bei einem LED-Lauflicht ist das total wurscht. Die Gefahr bei den GVs ist die Gewöhnung, also besser nicht dran gewöhnen globale Variablen zu verwenden, wenn man nicht weiß wie es eigentlich richtig geht. Eine schnelle Lösung ist halt nicht immer richtig. Beste Grüße public
Reinhard Kern schrieb: > Eben, das ist der Unterschied. Wer um alles soll denn bei einem > Temperaturregler für ein Aquarium die Temperatur manipulieren, wie von > static befürchtet - die Fische? Und wieso soll sie eine nicht globale > Variable davon abhalten, wenn man ihnen das schon zutraut? Ich hoffe inständig, ihr macht in eurer Firma: RK elektronik GmbH keine SW macht ... Da wollen einige Poster dem TO ein bisschen gutes SW Engineering beibringen und dann kommt der Chaos-Bastler Reinhard und mach alles zunichte. Pfui - schäm dich!
amateur schrieb: > Kapseln, ist das das was man seit neuestem in die Kaffeemaschine > schiebt ... und auch die ist inzwischen ein Embedded System mit jeder Menge SW.
Reinhard Kern schrieb: > Die von dir erwähnten 200000 Zeilen Code sind bei Embedded Controllern > bisher eher nicht die Regel. Da kann ich aber nur lachen. Ich arbeite seit mehreren Jahrzehnten als SW Entwickler im Embedded Bereich und kann dir versichern, dass es eine Reihe von Systemen gibt, die diese Zeilenanzahl aber locker erreichen.
Warum sich mit 10 Zeilen Code abfinden wenn es auch mit 1000 geht? In Zukunft wird die Programmgröße auch ein Instrument für die Marketingprofis werden, indem sich entsprechende Angaben in den Werbeprospekte gegenseitig überbieten. Kleine Controller werden dann dann nur noch ein Ziel für Hohn und Spott sein - wer hat den Kleinsten?
Tippgeber schrieb: > Warum sich mit 10 Zeilen Code abfinden wenn es auch mit 1000 geht? Weil der Faktor nicht 1:100 ist, sondern wesentlich weniger. Und es sogar so ist dass er sich mit steigender Programmgröße ins genau Gegenteil dessen verkehrt, was du hier suggerierst. Und weil es doch tatsächlich Programmierer gibt, die damit rechnen müssen, ihr Programm in den nächsten 10 Jahren noch in der Wartung zu haben und sich auch in 2, 3 oder 5 Jahren noch darin zurecht finden müssen ohne bei einer Erweiterung gleich erst mal alles zu zerstören.
Karl Heinz Buchegger schrieb: > Und weil es doch tatsächlich Programmierer gibt, die damit rechnen > > müssen, ihr Programm in den nächsten 10 Jahren noch in der Wartung zu > > haben Schade, in 10 Jahren bin ich hoffentlich in Rente. Ich hoffe, dass meine digitale Komfortklospülung mir dann immer schön was vorsingt.
Tempo schrieb: > Chaos-Bastler Reinhard Typisch Glaubenskrieger - weit und breit kein sachliches Argument, aber mit Beleidigungen nur so um sich werfen. Die meisten anderen führen hier wenigstens Gründe für ihre Meinung an, auch wenn ich nicht allen zustimmen kann, aber du betreibst nur das übliche substanzlose Shitstorming. Schade für das Forum hier, dass sich immer wieder jemand einmischen muss, der Pöbeln und Denken verwechselt. Gruss Reinhard
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.