Reihenfolge Initialisierung von static Membern

[Entwickler (Gast)]

Ich habe in zwei Klassen jeweils ein statisches Objekt, welche ich in 
zwei unterschiedlichen .cpp Dateien initialisier. Die main() befindet 
sich in einer dritten .cpp Datei.

Nun ist meine Frage, in welcher Reihenfolge werden diese initialisiert?

[EAF (Gast)]

Entwickler schrieb:
> Ich habe in zwei Klassen jeweils ein statisches Objekt, welche ich in
> zwei unterschiedlichen .cpp Dateien initialisier.

Das haut dir der Linker um die Ohren.

Also nein, deine Situation MUSS eine andere sein.

[Entwickler (Gast)]

Header a.hpp

class A{
  static int x;
};

Header b.hpp

class B{
  static int y;
};

Source a.cpp

int A::x = 0;

Source b.cpp

int B::y = 0;

[W.S. (Gast)]

Entwickler schrieb:
> Ich habe in zwei Klassen jeweils ein statisches Objekt, welche ich in
> zwei unterschiedlichen .cpp Dateien initialisier.

Wozu so ein krummes Konstrukt überhaupt andenken?

Normalerweise nimmt man Objekte für Zeugs, was zwar ein individuelles 
Innenleben haben kann, aber von außen für alle derartigen Objekte gleich 
aussieht und gleich funktioniert. Beispiel: grafische Elemente auf dem 
Display. Das eine ist ein Kringel, das andere ein Kreuzel oder so 
ähnlich. Sowas wird beim Instantiieren aufgesetzt und das erfolgt in der 
Datei, die diese Objektklasse definiert. Fertig.

W.S.

[N00B (Gast)]

Entwickler schrieb:
> Header a.hpp
> class A{
>   static int x;
> };
>
> Header b.hpp
> class B{
>   static int y;
> };
>
> Source a.cpp
> int A::x = 0;
>
> Source b.cpp
> int B::y = 0;

Iirc ist das undefiniert, müsste von linker abhängen

[Mikro 7. (mikro77)]

Entwickler schrieb:
> Nun ist meine Frage, in welcher Reihenfolge werden diese initialisiert?

https://stackoverflow.com/questions/1005685/c-static-initialization-order

Am besten also wrappen.

[N00B (Gast)]

Wobei die Reihenfolge nur bei Konstruktoreb überhaupt eine Rolle spielt. 
Globale Variablen werden intialisiert, bevor dein Programm überhaupt 
startet; daher hat die Reihenfolge keinen Effekt.

[Andreas M. (amesser)]

Entwickler schrieb:
> Nun ist meine Frage, in welcher Reihenfolge werden diese initialisiert?

Das kommt darauf an in welcher Reihenfolge der Linker den Code bindet. 
U.a spielt die Reihenfolge der Argumente des Linkers eine Rolle. Das 
Problem umgeht man in dem man eine statische Memberfunktion definiert, 
die man eine Referenz auf ein in der Funktion definierte statische 
Instanz zurückliefern lässt.

[Mombert H. (mh_mh)]

Entwickler schrieb:
> Nun ist meine Frage, in welcher Reihenfolge werden diese initialisiert?
Das ist undefiniert. Besorg dir ein ordentliches C++ Buch. Da wird 
erklärt, wie man mit so einer Situation umgeht.

W.S. schrieb:
> Entwickler schrieb:
>> Ich habe in zwei Klassen jeweils ein statisches Objekt, welche ich in
>> zwei unterschiedlichen .cpp Dateien initialisier.
>
> Wozu so ein krummes Konstrukt überhaupt andenken?
>
> Normalerweise nimmt man Objekte für Zeugs, was zwar ein individuelles
> Innenleben haben kann, aber von außen für alle derartigen Objekte gleich
> aussieht und gleich funktioniert. Beispiel: grafische Elemente auf dem
> Display. Das eine ist ein Kringel, das andere ein Kreuzel oder so
> ähnlich. Sowas wird beim Instantiieren aufgesetzt und das erfolgt in der
> Datei, die diese Objektklasse definiert. Fertig.
>
> W.S.

Was genau willst du damit sagen?

[EAF (Gast)]

N00B schrieb:
> Iirc ist das undefiniert, müsste von linker abhängen

Nein!
Die statischen Klasseneigenschaften sind völlig unabhängig voneinander 
und klar definiert.
Es gibt also kein konkurrierendes Verhalten.

[Mikro 7. (mikro77)]

N00B schrieb:
> Wobei die Reihenfolge nur bei Konstruktoreb überhaupt eine Rolle spielt.
> Globale Variablen werden intialisiert, bevor dein Programm überhaupt
> startet; daher hat die Reihenfolge keinen Effekt.

Es gibt Konstruktionen wo Funktionen bereits vor main aufgerufen werden.

[EAF (Gast)]

Nachtrag:
Damit ist die Reihenfolge auch völlig egal.
Irrelevant.

[N00B (Gast)]

Mikro 7. schrieb:
> N00B schrieb:
>
>> Wobei die Reihenfolge nur bei Konstruktoreb überhaupt eine Rolle spielt.
>> Globale Variablen werden intialisiert, bevor dein Programm überhaupt
>> startet; daher hat die Reihenfolge keinen Effekt.
>
> Es gibt Konstruktionen wo Funktionen bereits vor main aufgerufen werden.

Ich habe mich etwas unklar ausgedrückt: Variablen (im Sinne von int, 
char, …) werden iirc im Startup initialisiert, da ist die Reihenfolge 
egal (technisch gibt es eine).

Konstruktoren von Objekten werden vor Main() mit einer Reihenfolge 
abhängig davon, was der linker so treibt, aufgerufen.

[N00B (Gast)]

EAF schrieb:
> N00B schrieb:
>
>> Iirc ist das undefiniert, müsste von linker abhängen
>
> Nein!
> Die statischen Klasseneigenschaften sind völlig unabhängig voneinander
> und klar definiert.
> Es gibt also kein konkurrierendes Verhalten.

?

Nur weil es nichts gibt, was im dem Beispiel von der Reihenfolge 
abhängen könnte, heißt es nicht, dass es keine Reihenfolge gibt; ein 
Speicherbereich wird halt zuerst beschrieben (auf den Plattformen, die 
ich kenne).

[N00B (Gast)]

Entwickler schrieb:
> Header a.hpp
> class A{
>   static int x;
> };
>
> Header b.hpp
> class B{
>   static int y;
> };
>
> Source a.cpp
> int A::x = 0;
>
> Source b.cpp
> int B::y = 0;

Btw: das Beispiel wiederspricht sich mit deiner ursprünglichen Frage, 
wie ich gerade gemerkt habe, ints sind keine Objekte (und führen die 
Frage ad absurdum)

[Mombert H. (mh_mh)]

N00B schrieb:
> Btw: das Beispiel wiederspricht sich mit deiner ursprünglichen Frage,
> wie ich gerade gemerkt habe, ints sind keine Objekte (und führen die
> Frage ad absurdum)

A::x ist ein Objekt mit Typ int.

[Mikro 7. (mikro77)]

N00B schrieb:
> ...

/*global*/ int i = f() ;

Wenn nun f() auf eine globale Variable aus einer anderen Translation 
Unit zugreift, dann kann es durchaus sein, dass diese dort noch nicht 
initialisiert wurde.

[N00B (Gast)]

N00B schrieb:
> Entwickler schrieb:
>
>> Header a.hpp
>> class A{
>> static int x;
>> };
>> Header b.hpp
>> class B{
>> static int y;
>> };
>> Source a.cpp
>> int A::x = 0;
>> Source b.cpp
>> int B::y = 0;
>
> Btw: das Beispiel wiederspricht sich mit deiner ursprünglichen Frage,
> wie ich gerade gemerkt habe, ints sind keine Objekte (und führen die
> Frage ad absurdum)

Ups, ints sind doch Objekte...
Aber Objekte ohne Konstruktoren führen die Frage so oder so ad absurdum