Warum moeglichts keine globalen Variablen verwenden ?
-
Hallo,
ich komme aus der Großrechner-Welt (seit 1982) und da wird auch heute noch
viel mit COBOL/Assembler programmiert. DOrt gibt es eigentlich - ausser bei
externen Unterprogrammen - nur globale Variablen. Warum sollte man das in
C - da programmiere ich auch - nicht machen - ob ich jetzt ne
Funktion im C aufrufe oder einen Perform im Cobol oder nen Balr in
Assembler - das ist doch eigentlich wurscht. Außerdem sollte das
System eigentlich mit globalen Variablen performanter werden.
(Es braucht nix neu angelegt zu werden usw...). Man sollte es
halt grundsätzlich wohl nicht mischen - dann blickt wohl keiner mehr durch.
Ich hab schon einige Dinge in C entwickelt - von ner Pferdeverwaltung
bis zum Netzwerk-Server-Programm und hab mit globalen Variablen noch nie
Ärger bekommen - im Gegenteil man spart sich die oftmals lästige
Parameterübergabe an die Unterroutinen usw und es ist - zumindest fuer mich -
wesentlich übersichtlicher wie ein Feld int zaehler, das an 34 Stellen
definiert wird. Ähnlich sehe ich es auch mit dem ach so verpönten GOTO.
Wenns selbst im Kernel veerwendet wird, kanns ja nicht so böse sein - und
ein goto am Anfang einer Routine direkt zu deren Ende, falls nix zu tun ist,
macht es in meinen Augen auch übersichtlicher wie 20 verschachtelte ifs.
Wie gesagt - das ist nur meine persönliche Meinung und mich würde mal
interessieren, wie ihr so darüber denkt.
-
Ganz einfach: es fördert Spagetthi-Code
-
Ich komme auch aus der Großrechnerwelt und mir geht es genau andersrum. Ich vermisse in Cobol die Möglichkeit, mit lokalen Variablen zu arbeiten.
Gerade in alten Cobol-Programmen finde ich häufig nicht (oder nur schlecht) sprechende Variablennamen und man kann sich in einer Section nie sicher sein, ob der aktuelle Inhalt einer globalen Variablen nicht noch woanders benötigt wird, oder ob die Variable nun für den aktuellen Zweck benutzt werden kann.In C (zum Beispiel) dagegen kann ich in jeder Funktion eine evtl. benötigte Zählvariable anlegen, ohne mir darüber Gedanken machen zu müssen, ob ich sie nun i, i1 oder i2 benenne, da sie am Funktionsende wieder zerstört wird.
Nur mal so zwei Beispiele, die mir auf Anhieb einfallen.
-
Funktionen, die mit globaler Variablen arbeiten, sind nicht reentrant/thread-safe. Wenn man mit Threads arbeitet, muss man diese mit Mutex schützen, was andere Probleme mit sich führen kann, die wiederum teuer werden können (priority inversion bei RTOS z.b.).
Was den GOTOs angeht: ich bin einer, der hin und wieder GOTO verwendet, wenn das die Lesbarkeit erhöht, eher im Stil vom Linux, da kann GOTO eine (unnötige) mehrfache Verschachtelung ersparen. Zu viele GOTOs machen aber den Quellcode auf lange Sicht unlesbar und was unlesbar ist, ist unwartbar, vor allem, wenn man in einer Gruppe arbeitet.
-
pferdefreund schrieb:
Warum sollte man das in
C - da programmiere ich auch - nicht machen - ob ich jetzt ne
Funktion im C aufrufe oder einen Perform im Cobol oder nen Balr in
Assembler - das ist doch eigentlich wurscht.Es gibt den Spruch, dass man in jeder Sprache FORTRAN programmieren kann. Für COBOL gilt das wahrscheinlich genauso. Aber das ist dann so, wie wenn du eine Fremdsprache sprichst, in dem du jedes Wort einzeln übersetzt.
Im Übrigen ist diese Debatte vor ungefähr 30 bis 40 Jahren gelaufen, wieso ist in deinem Universum davon nichts angekommen? Das bringt echt nichts, dass wir das jetzt hier aufwärmen.
Außerdem sollte das System eigentlich mit globalen Variablen performanter werden.
(Es braucht nix neu angelegt zu werden usw...)Ganz falsch. Erstens kostet das Anlegen fast nichts, aber viel wichtiger ist, dass lokale Variablen in Registern gehalten werden können, während für globale Variablen im Allgemeinen immer ein Speicherzugriff notwendig ist. Auch sonst werden Optimierungen von globalen Variablen davon behindert, weil der Compiler bei jedem Aufruf einer externen Funktion davon ausgehen muss, dass sich die Werte aller globalen Variablen verändert haben könnten.
-
^^bei arrays kanns genau andersrum sein. um auf array-elemente zuzugreifen, die an eine funktion als pointer übergeben wurden (funktionsparameter sind ja auch nix anderes als lokale variablen), muss zur laufzeit oft indirekte adressierung (+offset) verwendet werden. haste das array als globales objekt, fällt das alles weg, weils der compiler schon ausgerechnet hat.
-
+fricky schrieb:
^^bei arrays kanns genau andersrum sein. um auf array-elemente zuzugreifen, die an eine funktion als pointer übergeben wurden (funktionsparameter sind ja auch nix anderes als lokale variablen), muss zur laufzeit oft indirekte adressierung (+offset) verwendet werden. haste das array als globales objekt, fällt das alles weg, weils der compiler schon ausgerechnet hat.
ich denke, es hat seine Vor- und Nachteile und hängt von der Arch. ab. Bei ARM kannst du über dem ldr Befehl sofort den offset angeben, was an sich kaum mehr Zyklen kostet
-
supertux schrieb:
Bei ARM kannst du über dem ldr Befehl sofort den offset angeben, was an sich kaum mehr Zyklen kostet
ja, ARMs sind schon spitze. nicht umsonst haben die sich so ausgebreitet. mein schnellster ARM läuft 'nur' mit 72Mhz CPU-clock, aber wenn der selbe code teilweise 20 mal schneller läuft, als auf einem anderen nicht-ARM prozessor (mit 24Mhz getaktet) bin ich schon beeindruckt.
-
Ganz falsch. Erstens kostet das Anlegen fast nichts, aber viel wichtiger ist, dass lokale Variablen in Registern gehalten werden können, während für globale Variablen im Allgemeinen immer ein Speicherzugriff notwendig ist. Auch sonst werden Optimierungen von globalen Variablen davon behindert, weil der Compiler bei jedem Aufruf einer externen Funktion davon ausgehen muss, dass sich die Werte aller globalen Variablen verändert haben könnten.
Man lernt immer was dazu - das mit den Registern wusste ich nicht.
Dann machts wohl wirklich Sinn.