Frage zu globalen Variablen
-
Hallo!
Vielleicht klingt das jetzt wie eine Anfängerfrage, vielleicht ist es auch solch einer. Aber ich bitte um Aufklärung von diesem ParadoxDAlso setidem wir C++ lernen wird uns gesagt, dass wir wehement(schreibt man hoffentlich so) kaum globale Variablen verwenden sollen.
Allerdings in einem anderen Fach(hardwarenahe Programmierung in C) arbeiten wir fast ausschließlich mit globalen Variablen (unter Verwendung von volatile oder static),defines (wird im C++-Fach überhaupt nicht gerne angesehen). ->hier kommt man nicht ohne globalen wirklich weiter
Dasselbe gilt auch für die Mikroprozessorprogrammierung in Assembler.In Systemprogrammierung in C (auf Linux) gilt wiederum das gleiche wie im Fach für C++.
Jetzt zu meiner endgültigen Frage:
Also was jetzt? So wie ich das sehe hat das nichts mit C++ vs. C zu tun (also nicht:C ist dreckig daher darf man da alles tun xD)
Was ist eure Expertenmeinung dazu?
-
ACnut schrieb:
Allerdings in einem anderen Fach(hardwarenahe Programmierung in C) arbeiten wir fast ausschließlich mit globalen Variablen (unter Verwendung von volatile oder static),defines (wird im C++-Fach überhaupt nicht gerne angesehen).
pfui
ACnut schrieb:
[...] ->hier kommt man nicht ohne globalen wirklich weiter
Wieso?
ACnut schrieb:
Jetzt zu meiner endgültigen Frage:
Also was jetzt? So wie ich das sehe hat das nichts mit C++ vs. C zu tun (also nicht:C ist dreckig daher darf man da alles tun xD)
Was ist eure Expertenmeinung dazu?Richtig, das hat nichts mit der Sprache zu tun, globale Variablen sind praktisch immer und überall Mist, ganz egal in welcher Sprache...
-
ACnut schrieb:
wehement(schreibt man hoffentlich so)
Nee. Kennst du google?
Globale Variablen sind schlecht, weil sie Abhängigkeiten schaffen, die nicht nötig sind und auf Dauer fast garantiert zu Problemen führen. Außerdem gibts noch technische Probleme, z.B. ist die Reihenfolge beim Zerstören von statischen Objekten nicht definiert.
Das trifft jetzt aber nicht unbedingt auf ein 100 Zeilen Microcontroller Projekt zu. Wenn die Aufgabe klar umrissen ist und du weißt, dass es nicht wesentlich größer wird, dann nimmst du auch die einfachste Lösung. Die ist dann evtl. auch besser lesbar und verständlicher.
Allerdings können auch manche Microcontroller Programme ziemlich groß und komplex werden, da würde man dann auch nicht mehr mit globalen Variablen arbeiten.
-
Die Leute die hardwarenahe Sachen schreiben (egal ob jetzt in C oder Assembler) sind zu 90% Fleischhauer. Denen ist alles was Softwaredesign angeht vollkommen schnuppe. Vermutlich deswegen, weil die nie grosse Programme schreiben, und sich daher nie die notwendigkeit ergeben hat zu lernen sie man "sauber" programmiert.
-
Endlich mal jemand der sich traut die Wahrheit auszusprechen.
-
Wir haben in FBS gelernt, keine globale Variablen zu verwenden und im Gegensatz zu Java wird das dabei strikt kontrolliert.
In C++ verwendet man auch manchmal Singletons und die sind ja nicht mehr als gekapselte globale Variablen. In Assembler gibt es diese Kapselung nicht und deswegen muss man manchmal globale Variablen verwenden, aber eigentlich arbeitet man auch hier hauptsächlich mit dem Stack.
-
Wenn es der Stack hergibt.
Manchmal muss man eben Resourcen sparen.
Zudem sieht man bei globalen Variablen gleich den RAM-Verbrauch nach dem compilieren.
-
Marthog schrieb:
In C++ verwendet man auch manchmal Singletons und die sind ja nicht mehr als gekapselte globale Variablen.
Nope, Singletons haben nichts mit globalen Variablen zu tun. Leider gibt es zahlreiche Leute, die nicht verstanden haben, was ein Singleton ist und Singleton als farbenfrohe Verpackung zum Tarnen ihrer globalen Variablen missbrauchen. Die Verpackung ändert aber natürlich nichts daran, dass es sich um eine globale Variable handelt, von "Kapselung" kann man da nicht wirklich sprechen, wenn du mich fragst...
-
ok, vehement und nicht wehement
(sieht aber meiner Meinung nach aber wie ein fremdes Wort aus ;))Globale Variablen sind schlecht, weil sie Abhängigkeiten schaffen, die nicht nötig sind und auf Dauer fast garantiert zu Problemen führen. Außerdem gibts noch technische Probleme, z.B. ist die Reihenfolge beim Zerstören von statischen Objekten nicht definiert.
dot
aber auch bei einem größeren code könnten die globalen variablen eine wichtige rolle haben oder? z.b. wenn ein programmierer riesen schnittstellen in seinen funktionen hat, nur damit derjenige globale variablen vermeiden kann?
ist das denn noch guter programmierstil?
ist denn ein mix aus beidem nicht eher ratsam?zu @dot: Wieso wir in der hardwarenahen programmierung ohne globalen variablen nicht serh weit kommen:
Wir arbeiten auf einem 16bit µC (2MHz xD) und z.b. in unsrem letzten projekt "oszilloskop" mussten wir werte vom Analog/Digital-Converter lesen in ein Ringpuffer schreiben, bei der jeweligen Bedingung triggern und aufs Display schreiben. Da wir einen (sehr) begrenzten Speicher bzw. eine langsame CPU haben, mussten wir so weit es geht sparsam mit den CPU-Zyklen umgehen. Ohne den globalen Variablen hätte die Übung wahrscheinlich nicht gscheit funktioniert, da es jetzt schon nur 1kHz-Sinussignale halbwegs noch schafft.DirkB schrieb:
Wenn es der Stack hergibt.
Manchmal muss man eben Resourcen sparen.
Zudem sieht man bei globalen Variablen gleich den RAM-Verbrauch nach dem compilieren.das mit dem RAM-Verbrauch von globalen Variablen sehen haben wir noch nicht , aber was wir gelernt haben (in hardwarenahe programmierung), ist dass viele lokale variablen den assemblercode "explodieren" lassen
So wie ich das jetzt aus dieser Diskussion sehen kann, sind die Leute die aus der Software-Engineering-Branche kommen strikt gegen globale Variablen und die wie hustbaer schon erwähnt hat, die im hardwarenahen Bereich arbeiten nichts gegen globale Varaiblen haben.
Darf ich das jetzt so seheb? Wobei ich immer noch nicht eine klare Antwort auf meine Frage bekommen habe
-
Das hat mit hardwarenah nichts zu tun, sondern mit den Resourcen. Wenn die begrenzt sind, verlierst du nicht so schnell den Überblick darüber.
Du "weisst" wann und wo die Funktion aufgerufen wird und kennst die Nebeneffekte*
Da verzichtet man auch auf ein Betriebssystem.Manchmal kann man nicht auf globale Variablen verzichten. Aber mach das erst, wenn du alle anderen Möglichkeiten probiert hast.
globale Variablen: Parameterübergabe bei grafischen Oberflächen
*Wunschdenken
-
Mit hardwarenahe Programmierung bzw. Mikroprozessorprogrammierung meinte ich die Fächer die bei uns so heißen
ok, das klingt logisch
fazit:
also wenn man weiß was man tut und alle pros und kontras in das problem hineinbezieht, dann darf man durchaus globale variablen benutzen
-
ACnut schrieb:
aber auch bei einem größeren code könnten die globalen variablen eine wichtige rolle haben oder? z.b. wenn ein programmierer riesen schnittstellen in seinen funktionen hat, nur damit derjenige globale variablen vermeiden kann?
Das ist natürlich auch nicht so schön. Aber braucht man auch unbedingt Klassen, die sehr viele Abhängigkeiten direkt brauchen? Sowas kann man vielleicht in mehrere Komponenten aufteilen, vielleicht ist so eine Schnittstelle auch ein Hinweis darauf, dass man die unterteilen sollte.
Gibt auch verschiedene Möglichkeiten, wie man mit sowas umgeht. Notfalls könnte man vielleicht so ein Context Objekt rumreichen. Das mache ich ab und zu, vor allem wenn mir (noch) nicht klar ist, was ich alles brauchen werde und wenn verschiedene Unterkomponenten beteiligt sind, die unterschiedliche Anforderungen haben. Die Objekte im Context kann man dann aber austauschen und die sind nicht global.
Wir haben in unserer Software auch viele Singletons, die als globale Variablen missbraucht werden. Und jeder benutzt sie dann. Das führt dann dazu, dass man Komponenten schlecht wiederverwenden kann. Sagen wir, es gibt eine Komponente "Datenbankverbindung" (nur ein Beispiel), und jeder benutzt da diesen Singleton, weil unsere Software eine "Datenbank" benutzt und jeder natürlich auch genau diese Datenbank meint. Aber dann muss jemand doch eine Komponente schreiben, die auf eine andere Datenbank zugreifen muss, sagen wir für die Replikation. Er würde gern ein paar Komponenten wiederverwenden, aber es geht nicht, weil sie auf die globale Datenbankinstanz zugreifen, die ihn aber nicht interessiert (oder er braucht eben 2 Datenbankinstanzen). Was wir bei sowas in letzter Zeit ab und zu machen, wir fügen eine Möglichkeit hinzu, die globale Singletoninstanz threadlokal zu überschreiben. Also meist ein Stackobjekt, das im Konstruktor über interne Funktionen von dem Singleton die eine Instanz überschreibt und im Destruktor wieder zurücksetzt. Damit muss man den ganzen bereits vorhandenen Code nicht komplett umbauen und hat etwas mehr Kontrolle. Ob das jetzt gut ist, weiß ich nicht. Es ist zumindest in unserem Kontext gut (genug).
-
ACnut schrieb:
also wenn man weiß was man tut...
Da liegt ja das Problem. Wer weiß das schon.
Das fängt schon damit an, das man Funktionen verwendet ohne die Doku dazu gelesen zu haben. Und hört mit blind aus dem Internet kopierten Code nicht auf.
-
Boah wenn selbst bei Mechanics (einer der besten Informatiker) seiner Firma so gefrickelt wird, dann verliere ich langsam die Hoffnung an die Existenz von guten Programmierern.
-
Irgendwo müssen ja die Lücken für die Nationalen Sicherheits Agenturen herkommen.
Und wenn eine Software sicher läuft, verdient man damit kein Geld mehr.
-
@Mechanics
da hast du Recht, eine Aufteilung der "Arbeit" ist sicher eine sehr gute Lösung, aber wenn man damit wieder zum übertreiben anfängt, entsteht ja wieder eine "indirekte Abhängigkeit". Ich glaube bevor man wieder die Lesbarkeit bzw. Überichtlichkeit verliert, sollte man einen Kompormiss eingehen:DirkB schrieb:
Manchmal kann man nicht auf globale Variablen verzichten. Aber mach das erst, wenn du alle anderen Möglichkeiten probiert hast.
da ich noch nicht in der Industrie bin und daher nicht weiß, wie dort die Aufgabenstellungen lauten, reden wir wsl von extremen Codelängengrößen (wenn für mich 37 Seiten (inkl. Doku) mit ungefähr 1000 Zeilen Code (laut CCCC)als relativ viel erscheint, ist für euch wsl ein Witz). Da werden dann Übersichtlichkeit bzw. Lesbarkeit eine etwas andere Bedeutung haben
DirkB schrieb:
ACnut schrieb:
also wenn man weiß was man tut...
Da liegt ja das Problem. Wer weiß das schon.
Das fängt schon damit an, das man Funktionen verwendet ohne die Doku dazu gelesen zu haben. Und hört mit blind aus dem Internet kopierten Code nicht auf.
wenn das niemand weiß, dann gibt es ja keine guten programmierer
problem bei den dokus ist, dass nach dem fertigen code einem das dokumentieren schwer fällt und daher derjenige extrem kurzgefasst paar zeilen "hinmalt" und solange das programm funktioniert und sich keiner beschwert ändert sich an der doku auch nichts(so nach dem stil:never change a running system)solange derjenige begründen kann wieso er da eine globale variable benützt und somit es für richtig hält, dann sollte es doch passen, oder?
-
ACnut schrieb:
solange derjenige begründen kann wieso er da eine globale variable benützt und somit es für richtig hält, dann sollte es doch passen, oder?
Solange, ja. Aber wenn dann eine Komponente zur Software hinzukommt (z.B. die zweite Datenbank in Mechanics Beispiel), dann passt das alles nicht und ist nur sehr schwer erweiterbar. Deswegen sollte man solange wie möglich auf globale Variablen verzichten.
dot schrieb:
Marthog schrieb:
In C++ verwendet man auch manchmal Singletons und die sind ja nicht mehr als gekapselte globale Variablen.
Nope, Singletons haben nichts mit globalen Variablen zu tun. Leider gibt es zahlreiche Leute, die nicht verstanden haben, was ein Singleton ist und Singleton als farbenfrohe Verpackung zum Tarnen ihrer globalen Variablen missbrauchen. Die Verpackung ändert aber natürlich nichts daran, dass es sich um eine globale Variable handelt, von "Kapselung" kann man da nicht wirklich sprechen, wenn du mich fragst...
Singletons enthalten eine Variable, auf die außerhalb ihrer Klasse bzw. Datei nicht direkt zugegriffen werden kann. Auf Assemblerebene ist es afaik nicht mehr möglich, den Zugriff auf die Variable zu blockieren, also kann sie jeder verändern oder zumindest lesen. Wenn man Assembler programmiert und ein Singleton braucht, muss man eine globale Variable hierfür verwenden.
-
Marthog schrieb:
Singletons enthalten eine Variable, auf die außerhalb ihrer Klasse bzw. Datei nicht direkt zugegriffen werden kann.
Und Flugzeuge enthalten Metall. Ein Singleton ist ein Typ, der nur einmal instanziert werden kann. Die Tatsache, dass die übliche Implementierung eines Singleton in C++ einen globalen Zugriffpunkt auf die einzige Instanz des Typs bietet und wie dies im Rahmen der Sprache normalerweise genau umgesetzt wird, ist irrelevant. Was den Singleton ausmacht ist, dass er nur einmal Instanziert werden kann. Alles andere ist eine Konsequenz des Singleton, aber nicht sein Zweck. Genau da unterscheiden sich globale Variablen von Singleton. Eine globale Variable ist ein Objekt eines bestimmten Typs. Ein Singleton ist ein Typ. Eine globale Variable verwend ich, um auszudrücken: Hier ist ein Objekt, das für jeden sichtbar ist. Einen Singleton verwend ich, um auszudrücken: Hier ist ein Typ, von dem es im ganzen Universum immer nur ein einziges Objekt geben kann. Das sind zwei völlig verschiedene Dinge.
Marthog schrieb:
Auf Assemblerebene ist es afaik nicht mehr möglich, den Zugriff auf die Variable zu blockieren, also kann sie jeder verändern oder zumindest lesen.
Die Frage ist, wie sinnvoll es ist, sich über Konzepte wie Singleton auf Assemblerebene zu unterhalten, da Assemlber keine Mittel bietet, diese Konzepte wirklich explizit auszudrücken...
-
dot schrieb:
Nope, Singletons haben nichts mit globalen Variablen zu tun.
Haben sie sehr wohl, aber das haben wir schon hier geklärt.
Ich weiss was du meinst, aber ein Singleton müssen wir im Bezug auf seine Implementierung in C++ anschauen, und nicht als abstraktes theoretisches Konzept mit der Idee einer einzelnen Instanz. Eben weil man dieses Konzept in C++ mittels globaler Variablen realisiert. Mit der abstrakten Definition verwirrst du nur Leute, weil jeder eine konkrete Vorstellung vom Begriff Singleton hat. Soweit ich weiss, sieht sogar das ursprüngliche Design Pattern die Implementierung mittels statischer/globaler Variablen vor, von Orthogonalität kann also keine Rede sein.
-
dot schrieb:
Marthog schrieb:
Auf Assemblerebene ist es afaik nicht mehr möglich, den Zugriff auf die Variable zu blockieren, also kann sie jeder verändern oder zumindest lesen.
Die Frage ist, wie sinnvoll es ist, sich über Konzepte wie Singleton auf Assemblerebene zu unterhalten, da Assemlber keine Mittel bietet, diese Konzepte wirklich explizit auszudrücken...
Der TE hat nach globalen Variablen und dem Unterschied dabei zwischen High- und Low-Level-Sprachen gefragt. Die High-level-Sprachen kennen das Singleton, bei Low-Level fehlt dieses, stattdessen muss man sich mit globalen Variablen eines selber basteln. Das heißt also, dass bei low-level für die gleiche Funktionalität unter bestimmten Umständen durchaus globale Variablen auftreten können/müssen.
