🚀 go-pugleaf

Vergesst bei der ganzen Diskussion zu globalen Objekten nciht, dass
das Problem unabhaengig davon ist, ob man Exception--Handling hat.
Der Punkt ist, dass bei Verwendung von globalen Objekten
Funktionen VOR main() aufgerufen werden.
Und zwar in einer UNDEFINIERTEN Reihenfolge.
So kann im Anwendungscode keine irgendwie geartete Initialisierung
stattfinden.
Selbst das Ausgeben von Fehlermeldungen mit IOStreams in Konstruktoren
ist dann kritisch, weil nicht sichergestellt ist, dass
die Objekte, wie "cerr" schon initialisiert sind.

Aus diesem Grund:
 - VERMEIDE GLOBALE OBJEKTE
Wenn es sich nicht vermeiden laesst:
 - KEINE Annahmen ueber igrendwelche Initialisierungen in Konstruktoren

Ist nicht schoen, ich weiss.
So weit mir bekannt ist, gab es auch immer wieder Diskussionen, die
Sprache in dieser Hinsicht (Diskussion einer Initialisierungs--Reihenfolge)
zu erweitern. Den aktuellen Stand weiss ich aber leider nicht.

Eine bessere Loesung wenn von ueberall Zugriff auf ein Objekt gebraucht wird,
ist vielleicht
ist die Verwendung von Hilfsfunktionen, die das Objekt beim ersten
Aufruf mit new erzeugen und dann immer eine Referenz des Objekts
liefern (ist mir gerade so eingefallen, korrigiert mich bitte).


>Globale Objekte bieten sich immer dann an, wenn Du bestimmte Dinge durch-
>fuehren willst, bevor main() startet. Bei einer Klassenblibliothek von mir
>sind das z.B. Registrierungen fuer persistente Objekte. Haette nicht jedes
>Modul ein oder mehrere statische Objekte, die die notwendigen Registrierungen
>durchfuehren, dann muesste der Programmierer das in jedem Programm zu Fuss
>durch Aufrufe von einzelnen Funktionen machen - und das waere bei der
>Vielzahl der persistenten Objekte eine ermuedende und auch sehr fehler-
>anfaellige Geschichte. Das eine Initialisierung nicht durchgefuehrt wurde
>merkst Du naemlich in dem Fall erst recht spaet bzw. u.U. in der Testphase
>ueberhaupt nicht.
Man kann auch bei jedem Zugriff pruefen, ob ein Objekt
existiert bzw. initialisiert ist und es ggf. in dem Moment erzeugen
bzw. initialisieren
(Konstruktor setzt Komponente "istInitialisiert" auf False
 und jeder Zugriff prueft das und ruft ggf. eine dann wirklich
 initialisierende Funktion auf)

>> Bestimmte Kodierungsstile werden oft deswegen als Bad Design bezeichnet,
>> weil sie letztendlich zu fehleranfälligem Code führen.  Globale Objekte
>> werden oft mit einer init()-Memberfunktion initialisiert (anstatt im
>> Konstruktor), weil zB argc,argv erst später zur Verfügung steht. 
>
>Ich habe bei mir kein einziges globales Objekt, das mit einer Init() Funktion
>initialisiert wird. Das was Du angibst (Zugriff auf argc und argv) ist einer
>der wenigen denkbaren Faelle, wo das notwendig sein sollte, dann aber liegt
>das Problem woanders, naemlich in der Trennung von Instantiierung und
>Initialisierung, nicht bei den globalen Objekten...
>Und wie oben genannt, waere (zumindest bei meiner Bibliothek) der _Verzicht_
>auf globale Objekte der eindeutig fehleranfaelligere und umstaendlichere
>Weg. 
>
Und was machst Du, wenn eine Initialisierung nicht moeglich ist?
(Hoffentlich keine Fehlermeldungen mit IOStreams)

>> Ebenso
>> ist die Einkapselung nicht mehr gegeben, wenn globale Strukturen überall 
>> im Code vorkommen; das gilt doch auch schon für C.
>
Hmmm, die Objekte sind global, die Daten darin doch immer noch
gekapselt, oder ?

--------
Nico                             address: BREDEX GmbH
email:   nico@bredex.de                   Nicolai Josuttis
                                          Fallersleber-Tor-Wall 23
phone:   +49 531 24330-0                  D-38100 Braunschweig
fax:     +49 531 24330-99                 Germany
--------