C++ globale Initialisierungsreihenfolge ignoriert Abhängigkeiten?

Question

Ich glaube, mein Problem am besten in Code beschrieben:

#include <stdio.h> 

struct Foo; 

extern Foo globalFoo; 

struct Foo { 
    Foo() { 
     printf("Foo::Foo()\n"); 
    } 

    void add() { 
     printf("Foo::add()\n"); 
    } 

    static int addToGlobal() { 
     printf("Foo::addToGlobal() START\n"); 

     globalFoo.add(); 

     printf("Foo::addToGlobal() END\n"); 

     return 0; 
    } 
}; 

Foo globalFoo; 

int dummy = Foo::addToGlobal(); 

int main() { 
    printf("main()\n"); 

    return 0; 
} 

Die obigen Drucke (mit gcc 4.4.3):

Foo::Foo() 
Foo::addToGlobal() START 
Foo::add() 
Foo::addToGlobal() END 
main() 

Das ist, was ich erwarte, und scheint logisch.

Allerdings, wenn ich die folgenden Zeilen tauschen:

Foo globalFoo; 
int dummy = Foo::addToGlobal(); 

in diese:

int dummy = Foo::addToGlobal(); 
Foo globalFoo; 

gibt das Programm die folgenden:

Foo::addToGlobal() START 
Foo::add() 
Foo::addToGlobal() END 
Foo::Foo() 
main() 

Es scheint Instanzmethoden Foo werden mit einer noch nicht vorhandenen Instanz aufgerufen wurde gebaut! Etwas so Einfaches wie das Verschieben der Deklaration einer Variablen in den globalen Gültigkeitsbereich beeinflusst das Verhalten des Programms, und das lässt mich glauben, dass (1) die Reihenfolge der Initialisierung von Globals nicht definiert ist und (2) die Reihenfolge der Initialisierung von Globals ignoriert alle Abhängigkeiten. Ist das richtig? Kann sichergestellt werden, dass der Konstruktor Foo vor der Initialisierung dummy aufgerufen wird?

Das Problem, das ich zu lösen versuche, füllt ein Repository von Elementen (eine statische Instanz von Foo) statisch. In meinem aktuellen Versuch verwende ich ein Makro, das (unter anderem) eine globale Variable (in einem anonymen Namensraum, um Namenskonflikte zu vermeiden) erstellt, deren Initialisierung die statische Initialisierung auslöst. Vielleicht gehe ich mein Problem aus dem falschen Blickwinkel an? Gibt es eine bessere Alternative (n)? Vielen Dank.

Answer 1

Lesen Sie in der Reihenfolge der Initialisierung die Antwort here.

Zum Lösen des Initialisierungsproblems können Sie das globale Element als statische lokale Variable in einer Funktion verwenden. Es Standard garantiert, dass die statische lokale Variable wird im ersten Aufruf der Funktion initialisiert werden:

class Foo { 
public: 
    static Foo& singleton() { 
     static Foo instance; 
     return instance; 
    } 
}; 

Ihre anderen globalen Variablen die Variable als Zugang würde dann:

Foo::singleton().add(); 

Beachten Sie, dass dies nicht generell ist als ein gutes Design angesehen, und auch, wenn dies die Initialisierung Probleme behebt, es nicht die Reihenfolge der Finalisierung zu lösen, so sollten Sie vorsichtig sein, nicht auf das Singleton zugreifen, nachdem es zerstört wurde.

Answer 2

(1) die Reihenfolge der Initialisierung der globalen Variablen nicht

Globale Variablen in einem einzigen Übersetzungseinheit (Quelldatei) definiert in der Reihenfolge initialisiert werden, in der sie definiert sind.

Die Reihenfolge der Initialisierung von globalen Variablen in verschiedenen Übersetzungseinheiten ist nicht spezifiziert.

(2) die Reihenfolge der Initialisierung von Globals ignoriert alle Abhängigkeiten

Rechts.

Kann sichergestellt werden, dass der Konstruktor von Foo vor der Dummy-Initialisierung aufgerufen wird?

Ja, wenn globalFoovordummy definiert ist, und sie sind in der gleichen Übersetzungseinheit.

Eine Option wäre, einen statischen Zeiger auf die globale Instanz zu haben; Solch ein Zeiger wird auf Null initialisiert, bevor irgendeine dynamische Initialisierung stattfindet; addToGlobal kann dann testen, ob der Zeiger Null ist; Wenn dies der Fall ist, ist es das erste Mal, dass global verwendet wird, und addToGlobal kann das globale Foo erstellen.

Answer 3

Sie haben Recht, die Initialisierung von Globals zwischen Übersetzungseinheiten ist nicht definiert. Es ist möglich, dies mit der singleton pattern umgehen. Seien Sie jedoch gewarnt, dass dieses Entwurfsmuster häufig missbraucht wird. Seien Sie auch gewarnt, dass die Reihenfolge oder Zerstörung von Globals auch nicht definiert ist, falls Sie Abhängigkeiten in den Destruktoren haben.

Answer 4

C++ fehlt etwas wie Ada's pragma elaborate, so dass Sie keine Annahmen über die Reihenfolge der Initalisierungen machen können. Sorry. Es ist scheiße, aber das ist das Design.

Answer 5

Wie wäre es, wenn die statische globale Variable ein auf nullptr initialisierter Zeiger wäre? Dann, bevor ein anderes globales Objekt versucht, das Objekt zu verwenden, nach seiner Erstellung suchen und bei Bedarf erstellen. Dies funktionierte für mich zum Erstellen einer globalen Registrierung von Klassenerstellern, wo man neue Klassen hinzufügen konnte, ohne die Datei zu ändern, die die Registrierung behandelt hatte. dh

class Factory { 
    static map<string, Creator*>* theTable; 
    static void register1(const string& string, Creator* creator); 
... 
}; 
... 
map<string, Creator*>* Factory::theTable= nullptr; 
void Factory::register1(const string& theName, Creator* creator) { 
    if (!theTable) theTable=new map<string, Creator*>; 
    (*theTable)[theName]=creator; 
} 

Dies kompiliert und arbeitete mit VC++ in Visual Studio 2015

ich vor diesem

class Factory { 
    public: 
     static map<string, Creator*> theTable; 
     static map<string, Creator*>& getTable(); 
     static void register1(const string& string, Creator* creator); 
} 
map<string, Creator*> Factory::theTable; 
map<string, Creator*>& Factory::getTable() { 
    return theTable; 
} 
void Factory::register1(const string& theString, Creator* creator) { 
    getTable()[theString]=creator; // fails if executed before theTable is created 

} 

mit versucht hatte, aber ich Ausnahmen geworfen noch hatte, als thetable nicht vorher erstellt wurde versucht, Einfügen eines Eintrags in die Map, was passieren kann, wenn die Registrierung der Klasse in einer separaten Kompilierungseinheit von der Fabriklogik behandelt wird.