🚀 go-pugleaf

On Tue, 15 Aug 95 23:22:58 +0200, Heiko Zschernitz wrote:

>class B
>{
>   int x;
>public:
>   B(){};
>   TuWas() { x = 1; }
>};

>A a;
>B b;

>A::A()
>{ b.TuWas();
>}

>Das sollte meiner Meinung nach aber ebenfalls funktionieren, weil das
>Objekt b statisch erzeugt wird. Dann ist der Speicher ja bereits vorhanden
>und die Adresse bekannt, wenn b.TuWas() aufgerufen wird.

>Uebrigens sollte man sich nicht darauf verlassen, dass die Konstruktoren
>von a und b in dieser Reihenfolge aufgerufen werden. Je nach verwendetem
>Compiler/Linker kann die Reihenfolge der Initialisierung von statischen
>Objekten variieren (vermute ich). 

Volle Zustimmung: die statischen Objekte werden vom Compiler/Linker "je nach
Laune" irgendwann vor dem Aufruf von main() initialisiert. Wenn ein Programm aus
mehreren Modulen (.OBJ-Dateien unter DOS) besteht, kann es passieren, dass das
Programm einmal laeuft und einmal nicht, je nach der Reihenfolge, in der man die
Module dem Linker vorsetzt. 

Beispiel-Katastrophe: 

Zum Debuggen setzt man sich einen statischen Stream in eines der Module:

ofstream Log("alles.log");

In verschiedenen Modulen verteilt man dann jede Menge statische Objekte, deren
Konstruktoren froehlich in den Log-Stream schreiben. Mit etwas "Glueck" schafft
man es dann, dass das Programm laeuft. Wenn man dann die Anordnung der
OBJ-Dateien beim Aufruf des Linkers etwas veraendert, semmelt das Programm
gnadenlos ab ("komisch, komisch, ich hab doch gar nichts veraendert?!").


Tschuess...
		Michael