globale variablen

[markus lemcke]

hi,

was ist eigentlich so verweflich dran wenn man globale variablen definiert?
bei mir im geschäft ist das beinahe todsünde <br>
warum?<br>

gruß

markus

[Andreas Kosch]

Hallo Markus,

weil globale Variablen nicht mehr so recht in die heutige Zeit passen, sondern von den meisten in die Kategorie "Spagetti-Code" eingeordnet werden. Im Gegensatz zur objektorientierten Programmierung lässt sich der Zugriff auf globale Variablen nicht kontrollieren, d.h. der Entwickler muss selbst aufpassen, dass sich verschiedene Programmteile nicht untereinander ins Gehege kommen. Dies gilt immer dann im Besonderen, wenn Threads im Spiel sind.

P.S: In "modernen" mehrschichtigen Anwendungen, die aus zustandlosen COM+ Objekten bestehen, kann es bereits technisch gesehen keine globalen Variablen geben, weil es keine EXE gibt, die man selbst compilieren darf. Hier sind die in der DLL deklarierten globalen Variablen nur im eigenen Modul gültig, aber niemals global für die ganze Anwendung

[markus lemcke]

hi andreas,

deine antwort klingt sehr philosophisch!
gibt es auch fachliche gründe die dagegen sprechen?
was nimmt man als alternative?

gruß

marku

[Hagen Reddmann]

Im Grunde ist es nicht verwerflich. Ein Todsünde ist es in extreme zu verfallen, also entweder alles mit globalen Variablen zu coden oder zu behaupten globale Variablen wären immer schlecht und ein Todsünde. Globale Variablen sollten wie ALLES mit bedacht eingesetzt werden. <br>
<li>sie benötigen zur gesammten Laufzeit ihren Speicher, ein riesiges Array wird also seinen Speicher als globale Variable NIE freigeben.
<li>sie können, wenn sie im interface Bereich eine Unit deklariert wurden auch aus ALLEN Units die diese Unit nutzen gelesen und verändert werden.
<li>das die Unit von der Veränderung solcher Variablen NICHTS mitbekommt stimmt nur teilweise, da ja eine Schattenvariable im implementationsbereich definiert werden könnte.<br>

D.h. falls Du irgendwelche Daten, permanent benötigst, die unter Umständen aus vielen proceduren herraus ausgewertet werden, dann sind globale variablen eine Alternative, besonders aus Performanceaspekten herraus. Der Scope/Einzugsbereich einer globalen Variable ist also global. Ob nun diese Variable im Interface oder lokal zur Unit in deren Implementierung deklariert wird, hängt nun davon ob ob externe Units diese Variale modifizieren dürfen. Sollte sie Readonly, also NUR sichtbar sein empfiehlt es sich eine Funktion zu nutzen die die lokale variable als Result zurückgibt.<br>

<B>was absolut KEINE globale Variable sein sollte</b>!
alles was LOKAL gültig ist wie z.b. I:Integer einer for I := 0 to X schleife !!<br>

WENN eine globale Variable eine Todsünde IST, warum sind dann ALLE SysUtils Variablen wie CurrencyString/ShortDateFormat oder sogar die globalen Formularvariablen durch Borland als global definiert ?? Wenn es keine globalen Variablen gäbe wäre Delphi~~JAVA.

Gruß Hage

[Andreas Kosch]

Hallo Hagen,

in den .NET-Sprachen (C#, VB .NET usw.) lässt der Compiler keine globalen Variablen mehr zu (alles ist ein Objekt). Es gab vor Jahren einmal bei Microsoft Press ein dickes Buch (<i>Code Complete</i>), indem u.a. das Ergebnis einer umfangreichen Untersuchen war, aus welchen Gründen Software-Projekt gescheitert sind. Die durch globale Variablen verursachten Bugs und Seiteneffekte standen sehr weit oben :-)
&#10

[Hagen Reddmann]

Jo, es kommt halt auf den Programmierer an. Ich jedenfalls überlege mir dreimal ob es unbedingt eine globale var sein muss, und wenn ja dann meistens aus performancegründen lokal zur unit.
Ich habe mal so meine Sourcen durchgeschaut. Im Durchschnitt benutzt nur jede 5. Unit (keine Formularunits) globale vars.
Nur, wenn C# KEINE solche vars ermöglicht frage ich mich wie ich z.B. ein einzigstes Application Object per RunTime verwalten will.
Grundsätzlich finde ich Programmiersprachen die eine klare Struktur mit rel. wenig Befehlen unterstützen sehr gut, besonders in denen der Coder nicht alle Freiheiten hat. ABER, solche übertreibungen wie in JAVA oder der komplette Verzicht auf globale vars sind für mich eine "Entmündigung" der programmierer. Wir machen einen Job der geistige Arbeit benötigt also kann man wohl erwarten das ein Coder auch denken kann.

Gruß Hage

[Andreas Kosch]

Hallo Hagen,

ja solange nur <b>ein</b> Entwickler am Sourcecode der Anwendung rumfummelt, hast Du selbstverständlich völlig Recht. Aber .NET verspricht ja auch, dass viele Leute gleichzeitig in verschiedenen Sprachen an einem Projekt schreiben dürfen, wobei die Teile der Anwendung durchaus auf verschiedenen Rechnern (Servern) laufen können. Und in diesem Kontext würde man globale Variablen nur sehr schwer unter Kontrolle halten können, zumal ja eine globale Varibable für Module, die auf verschiedenen Rechnern laufen, sowie sinnlos wäre.

Für die .NET-Sprachen ist alles ein Objekt, für das die bereits von Object Pascal her bekannten Sichtbarkeits-Direktiven (Private etc.) zugewiesen werden.

[Jens Schumann]

Hallo,<br>
interessant, interessant !!! Angenommen ich habe globale Integer Variable. Da globale Variablen ja einen schlechten Ruf haben, mache ich mir ein globales Objekt.<br>
<pre>
TGlobInteger = class(TObject)<br>
private<br>
FGlobInt : Integer;<br>
public<br>
property GLobInt : Integer read FGLobInt write FGlobInt;<br>
end;<br>
...<br>
var<br>
GlobInteger : TGlobInteger;<br>
implementation
...<br>
initialization<br>
GlobInteger:=TGlobInteger.Create;<br>
finalization<br>
GlobInteger.Free;<br>
end.<br>
</pre>

Jetzt habe ich anstatt einer globalen Variablen ein globales Objekt. Wo ist da jetzt der Unterschied?<br>Jens Schuman

[markus lemcke]

genau jens!! das interessiert mich auch *lach*

gruß

marku

[Andreas Kosch]

Hallo,

wenn die Objekt-Instanz in einer <b>globalen Variablen</b> gespeichert wird, ist natürlich das Umverpacken in ein Objekt völlig sinnlos. Das Ganze funktioniert erst dann, wenn die Sprache (und der Compiler) dieses Konzept unterstützt.

Alle .NET-Sprachen werden beim Compilieren nur in einen Zwischencode (<b>MSIL</b> alias Microsoft Intermediate Language) übersetzt, der auf die <b>CLR</b> (Common Language Runtime) aufsetzt. Erst beim <b>ersten</b> Aufruf auf diesem Rechner kommt der JIT-Compiler (Just-In-Time-Compiler) von .NET ins Spiel, der diesen Zwischencode je nach der vorgefundenen CPU in direkt ausführbare Prozessoranweisungen übersetzt. Da der Entwickler und sein Compiler nicht mehr die volle Kontrolle hat (genauer gesagt, "sehen" wir niemals die CLR-Ebene unseres "Sourcecodes", wo man globale Daten definieren könnte), kann die CLR alle notwendigen Zwischenschritte (um zum Beispiel eine Objektinstanz zu finden) völlig transparent dazwischenschieben. In Object Pascal würde sich hinter der Instanzvariablen ein Zeiger auf die Adresse des Objekts im Arbeitsspeicher befinden, aber in .NET werden im Normalfall Zeiger nicht unterstützt (es sei denn, man kennzeichnet seinen Sourcecode an dieser Stelle als unsicheren Code). Diese Details sollen nur eins verdeutlichen - .NET funktioniert anders als wir es bisher gewohnt waren. Man kann also erst dann mit Object Pascal diesen neuen Weg beschreiten, wenn Delphi die CLR unterstüzt und ebenfalls nur noch den MSIL-Zwischencode generiert.

P.S: Die .NET-Sprache C# und die CLR wurde zu grossen Teil von <i>Anders Hejlsberg</i> (dem Vater von Turbo Pascal, Borland Pascal 7, Delphi 1, 2 und 3) konzipiert. Da er einer der wenigen noch lebenden Genies auf diesem Planeten ist, hat das Hand und Fuss :-

[markus lemcke]

ähm..... hast du es verstanden jens?
....ich habe den sinn des dichters worte nicht so ganz erfasst...



gruß

marku

[markus lemcke]

wo ist gesine mit dem entschlüsselungscode :

[Andreas Kosch]

Hallo Markus,

vielleicht hilft die folgende nicht ganz exakte Umschreibung weiter: Du kennst doch bestimmt den Unterschied zwischen Assembler und Object Pascal. Du schreibst in Delphi Dein Programm in Object Pascal, und der Delphi-Compiler übersetzt das in die vergleichbaren Assembler-Anweisungen (weit hergeholt), so dass Du dich gar nicht mehr um die Assembler-Details kümmern musst.

Bei einer .NET-Sprache ist das ähnlich - Du schreibst nicht mehr direkt den Source-Code, den der Compiler von .NET "sieht", sondern Du beschreibst Deine Objekte mit ihrern Eigenschaften und Attributen und beim "Compilieren" in der Entwicklungsumgebung generiert diese den "echten" Sourcecode, den der JIT-Compiler von .NET dann "richtig" übersetzt. Zum Beispiel reicht es aus, einer eigenen Methode nur das Attribut <b>[WebMethod]</b> zuzuweisen - .NET sorgt dann automatisch dafür, dass diese Methode im Internet über SOAP aufgerufen werden kann. In Delphi musst Du dafür speziellen SOAP-Komponenten verwenden und alles selbst schreiben, während bei .NET nur <b>ein Attribut</b> ausreicht (da der Rest von .NET automatisch im Hintergrund erledigt wird)

[markus lemcke]

danke andreas!

[Hagen Reddmann]

@Andreas, soviel ich weiß wurde aber PASCAL von Nicolaus Wirth entwickelt Und Anders hat es nur weiterentwickelt, wodurch eben auch vorinitialisierte Konstanten entstanden die später durch vorinitialisierte Variablen ersetzt wurden. Oder das overloading eingeführt wurde das im Zusammenspiel mit Default Parametern langezeit nicht funktionierte. Auch die goto's, continue, break sind erst nach Wirth in Borland PASCAL integriert wurden.

Appropo .NET: Wenn MS diesen JIT Compiler entwickelt und somit das hauptsächliche KnownHow besitzt, wird MS ja auch in der Lage sein meinen mit Delphi-NET erzeugten Zwischen-Code zu disassemblieren. Bei diesem Zischencode ist es ja das "lustige" das alle Variablen/Parameter/proceduren/Objecte als deren Deklaration vorliegen. D.h. es würde in großem Umfang tatsächlich möglich aus dem Zwischencode zu fast 100% den Quelltext zu erzeugen. Im grunde ist das so als wenn ich mein jetziges Delphi Program MIT TDW DebugInfos compiliere. Alles was notwendig ist wie Bezeichner, Datentypen und alle Deklarationen sind in diesen DegubInfos gespeichert. Es wäre demnach rel. einfach den Source wiederherzustellen.

Ok, .NET ist ein öffentlicher Standard und das gleiche was MS coden kann könnten auch andere. Nur M$ MUSS diesen JIT Compiler coden und erhält damit wohl einen großen Vorsprung.

Gruß Hage