ich schreibe an einer Bibliothek, die, wenn sie mit einem Programm gelinkt wird, vor bzw. nach dem Aufruf von main() Code ausführen können muss (Initialisierer/Finalisierer).

Dazu habe ich mich eines Tricks bedient, der die Konstruktoren von globalen Objekten ausnutzt:

class Initializer
{
	Initializer() { puts("initialisiert!"); }
} initializer;

Unter Linux funktioniert das bis jetzt gut, meine Bibliothek wird dynamisch gebunden und die Initialisierer initialisieren.
Unter Windows siehts anders aus: Klassen per DLL importieren ist ein Graus, und da es eh keine Paketverwaltung o.ä. gibt, ist es die beste Methode, das statisch zu linken.

Jetzt ist es nur leider so, dass das Objekt irgendwie nicht erstellt wird, wenn es sich in der statischen Bibliothek befindet. Wenn ich stattdessen die Objektdateien direkt mit dem Programm linke, funktioniert alles problemlos.

Ich verwende MinGW (und darauf bin ich angewiesen, um Cross-kompilieren zu können). Beim Erstellen der Bibliothek wird anscheinend eine Symboltabelle generiert, die das Initialisierer-Objekt nicht enthält (Spekulation).

Kann man den Linker dazu bringen, die .o-Dateien einzeln mit dem Programm zu binden anstatt die Tabellen zu verwenden, oder gibt es vielleicht eine ganz andere Lösung für das Problem?

Danke.

Ich habe mal vor sehr vielen Jahren etwas Ähnliches (automatische Registrierung für eine Factory) versucht und bin auch darauf hereingefallen. Beim Aufteilen des Projektes in unterschiedliche LIBs hat nichts mehr funktioniert

Ansonsten spricht auch nichts gegen eine normale init-funktion.

Kann man den Linker dazu bringen, die .o-Dateien einzeln mit dem Programm zu binden anstatt die Tabellen zu verwenden, oder gibt es vielleicht eine ganz andere Lösung für das Problem?

Ich kenne folgenden Workaround:

// DeineLibrary.h --------------------------------------------

namespace Detail {

class Initializer;
Initializer const& GetInitializer();

namespace {

Initializer const& g_initializer = GetInitializer();

} // namespace

} // namespace Detail

// DeineLibrary.cpp ------------------------------------------

namespace Detail {

class Initializer {
    // ...
};

Initializer const& GetInitializer()
{
    static Initializer s_initializer;
    return s_initializer;
}

So wie ich das verstehe, ist dann auch laut Standard garantiert, dass s_initializer in GetInitializer() immer konstruiert wird, auch wenn g_initializer nirgends referenziert wird.
Wobei ... dass es laut Standard garantiert ist, heisst natürlich nicht, dass es auch überall wirklich funktioniert

Ansonsten spricht auch nichts gegen eine normale init-funktion.

Hihi, doch. Dass man sie aufrufen muss

Ich kenne folgenden Workaround.....

Du bist ein Gott! Das hat mich 2 Tage gekostet Läuft einwandfrei.

Für Copy&Paste-freudige, das sind meine Initialisierermakros:

#define declare_initializer(identifier) \
	class identifier { \
		public: \
			identifier(); \
	}; \
	identifier const & get##identifier(); \
	namespace { identifier const & ref##identifier  = get##identifier(); } 

#define implement_initializer(identifier) \
	identifier const & get##identifier() { \
		static identifier instance; \
		return instance; \
	} \
	identifier::identifier()

Für einen neuen Initialisierer:

// In einem Header, der irgendwo im Zielprojekt eingebunden wird
declare_initializer(MyInitializer);

// In der Library
implement_initializer(MyInitializer)
{
	// Code
}

Finalisierer funktionieren analog, nur muss man dabei den Destruktor statt den Konstruktor definieren.

Edit: Kommando zurück, geht doch ein bisschen anders

const Initializer& GetInitializer(); // wie gehabt

namespace
{ 
    const Initializer& ref = GetInitializer();
}

Und muss GetInitializer() ausserhalb des anonymen Namensraums stehen? Besteht damit nicht nur die Gefahr eines potentiellen Namenskonflikts?

Die Header deswegen, damit man in jeder Übersetzungseinheit wo die Library XYZ benutzt wird, ein eigenes Ding (statische Variable) hat, dessen Initialisierung dazu führt, dass die GetInitializer() Funktion ausgeführt wird. (D.h. natürlich diese Header muss dann von allen Headern der Library XYZ includiert werden, sonst funktiert der Trick ja nichtmehr)

Ohne diesen Trick könnte (dürfte, laut Standard) der Compilier/Linker wieder die ganze Initializer-Instanz weglassen, so lange keine Funktionen aus der Übersetzungseinheit der Library in der die Initializer-Instanz definiert ist aufgerufen wird.

Also konkret, wenn du dein "refFoo" in foo.cpp definierst, der Anwender aber keine einzige Funktion aus foo.cpp aufruft, dann kann (darf) der Compiler foo.cpp einfach ganz weglassen, inklusive "refFoo".
Wenn das OK ist, dann ... ist es OK

Allerdings gibt es Fälle wo es nicht OK ist, und dann kann man mit eben diesem Trick arbeiten.

Achja... die Notwendigkeit des anonymen Namespace ergibt sich aus der Notwendigkeit der Header: ohne den hätte man nämlich ein mehrfach definiertes Symbol. (Man könnte natürlich "static" statt einem anonymen Namespace verwenden, aber ich verwende halt in solchen Fällen immer anonyme Namespaces)

Reicht eigentlich auch eine globale Funktion?

Die läuft wie gesagt Gefahr, wegoptimiert zu werden.

hustbaer schrieb:

@.trion:
Wenn ich mich richtig erinnere sind sowohl die Header als auch der anonyme Namespace nötig.

Fehler meinerseits, hat wegen einer falschen Linkereinstellung so ausgesehen als würde es funktionieren. Ist oben gefixt und geht jetzt.
Danke nochmal.

Die läuft wie gesagt Gefahr, wegoptimiert zu werden.

Nein, ich meine eine Funktion (halt wie die static -Memberfunktion), keine Variable. Warum sollte die eher wegoptimiert werden als die Memberfunktion?

Und für Cleanup braucht man sowieso ne Klasse.

Zur Initialisierung globaler Variablen habe ich im C++-Standard bisher nur das gefunden:

§3.6.2/1 Initialization of non-local objects schrieb:

Objects with static storage duration (3.7.1) shall be zero-initialized (8.5) before any other initializationtakes place. Zero-initialization and initialization with a constant expression are collectively called static initialization; all other initialization is dynamic initialization. Objects of POD types (3.9) with static storage duration initialized with constant expressions (5.19) shall be initialized before any dynamic initialization takes place. Objects with static storage duration defined in namespace scope in the same translation unit and dynamically initialized shall be initialized in the order in which their definition appears in the translation unit.

Heisst das nicht, dass globale Objekte ("static storage duration") mit dynamischer Initialisierung innerhalb einer ÜE initialisiert werden müssen, und zwar in der Deklarationsreihenfolge? Oder ist das eher so zu verstehen, dass wenn sie initialisiert werden, die Reihenfolge eingehalten werden muss? Oder hat das überhaupt nichts damit zu tun?

Ich habe nämlich ebenfalls so eine Initialisierung vor. Die SFML-Bibliothek hat auch sowas mit dem klassischen Ansatz (alles in .cpp-Datei) gelöst und es scheint nicht wirklich Probleme zu geben...

Okay, danke.

Zur Initialisierung globaler Variablen habe ich im C++-Standard bisher nur das gefunden:

§3.6.2/1 Initialization of non-local objects schrieb:

Objects with static storage duration (3.7.1) shall be zero-initialized (8.5) before any other initializationtakes place. Zero-initialization and initialization with a constant expression are collectively called static initialization; all other initialization is dynamic initialization. Objects of POD types (3.9) with static storage duration initialized with constant expressions (5.19) shall be initialized before any dynamic initialization takes place. Objects with static storage duration defined in namespace scope in the same translation unit and dynamically initialized shall be initialized in the order in which their definition appears in the translation unit.

Heisst das nicht, dass globale Objekte ("static storage duration") mit dynamischer Initialisierung innerhalb einer ÜE initialisiert werden müssen, und zwar in der Deklarationsreihenfolge? Oder ist das eher so zu verstehen, dass wenn sie initialisiert werden, die Reihenfolge eingehalten werden muss? Oder hat das überhaupt nichts damit zu tun?

Also so, wie ich das sehe kommt da der erste Satz (fett) zum tragen. Das heisst, dass sie immer 0 Initialisiert werden. Dass es so ist merkt man ja auch, dass die statischen Sachen im .bss Segment liegen, welches ja 0 Initialisiert ist. Oder verstehe ich dich mal wieder falsch?

Oder ist das eher so zu verstehen, dass wenn sie initialisiert werden, die Reihenfolge eingehalten werden muss?

Ja, genau das ist das Problem.

Lies mal zwei Punkte weiter unten:

§3.6.2/3 schrieb:

It is implementation-defined whether or not the dynamic initialization (8.5, 9.4, 12.1, 12.6.1) of an object of
namespace scope is done before the first statement of main. If the initialization is deferred to some point
in time after the first statement of main, it shall occur before the first use of any function or object defined
in the same translation unit as the object to be initialized.

Das impliziert, dass das Objekt gar nicht initialisiert werden muss, wenn nie Funktionen oder Objekte aus der Translation Unit aufgerufen/verwendet werden.

D.h. ...

Unproblematisch:

// in einem .cpp File:

namespace {

Foo g_somethingThatBarNeeds = MakeFoo();

} // namespace

Bar::Bar() // "use of a function" -> g_somethingThatBarNeeds muss initialisiert worden sein bevor Bar::Bar() läuft (*)
{
    m_magicValue = g_somethingThatBarNeeds.GetMagicValue(); // ... d.h. wir können es hier Gefahrlos verwenden
}

//*: ausgenommen Bar::Bar wird selbst während der Initialisierung eines "object with static storage duration defined in namespace scope" aufgerufen,
//   dann haben wir das allseits beliebte "initialization order fiasco" und alles geht den Bach runter :^)

Unproblematisch deswegen, weil g_somethingThatBarNeeds ja nicht gerbaucht wird, so lange keine "Bar" erzeugt werden. Und wenn "Bar" erzeugt werden ist auch garantiert dass g_somethingThatBarNeeds initialisiert wird.

Problematisch:

// in einem .cpp File:

namespace {

class MyFactory { ... };

int RegisterMyFactory()
{
    static MyFactory fac;
    ::RegisterFactory(&fac);
}

int g_registerHelper = RegisterMyFactory();

} // namespace

Problematisch deswegen, weil es hier u.U. gar keine Funktionen in der Translation Unit gibt, die direkt von aussen aufgerufen werden dürfen/können.
Die Absicht wäre hier RegisterMyFactory() nur wegen der Nebeneffekte (nämlich das Registrieren der Factory) auszuführen. Wenn der Compiler aber meint, kann er die Initialisierung von g_registerHelper einfach weglassen, da ja nie Funktionen aus der Übersetzungseinheit aufgerufen werden.

Ich kenne zwar keine Implementierung die den Standard soweit ausreizt dass die Initialisierung nach dem ersten Statement von main() passiert. Allerdings gibt es viele die eben das was ganz wegoptimiert werden kann auch ganz wegoptimieren.

Das ist grundsätzlich auch OK, da der Linker dadurch Teile verwerfen kann, die nicht gebraucht werden. Nur führt es eben auch dazu, dass das Registrieren von MyFactory so wie im Beispiel oben nicht funktioniert.

Als Workaround packen wir eine dynamisch initialisierte Variable in jede Übersetzungseinheit, in der Code aus unserer Library verwendet wird. Da wir die Header-Files unserer Library kontrollieren geht das einfach, wir machen einfach ein "mylib/common.h" das von allen andere "mylib/*.h" Files inkludiert wird, und da drin steht der Code den ich hier ursprünglich gepostet habe.

Natürlich gibt es auch wieder Fälle wo selbst das nicht funktioniert, nämlich wenn wir nicht wollen/nicht erzwingen können dass ein Clientprogramm so ein Headerfile inkludiert. z.B. weil die .lib bloss wie im "MyFactory" Beispiel ein Plugin registrieren soll, und wir sie nur beim Linken angeben wollen/können. Das lässt sich über Standard-C++ dann nichtmehr erschlagen.

Ich hab's nicht ausprobiert, aber bei MSVC könnte es sein dass man das Wegoptimieren von solchen Variablen über

#pragma comment(linker, "/include:__mySymbol")

verbieten kann.
Also verbieten kann man es damit sicher, aber was ich nicht weiss, ist, ob es reicht wenn das in der .lib steht, oder ob dieses #pragma im Code der .exe/.dll stehen müsste. Wenn letzteres, dann wäre es für das worum es hier geht ja wieder witzlos.

Achja, falls jmd. weiss ob/wie man das "Behalten" einer Variable mit GCC erzwingen kann... wäre auch interessant.

p.S.:
Der Workaround verlässt sich auch darauf, dass der Compiler/Linker genau das nicht macht was er dürfte, aber kein mir bekannter Compiler/Linker wirklich macht: die Initialisierung zu verzögern. In einigen Fällen wäre das nämlich genau so ein Problem, da die Initialisierung dann zu spät erfolgen würde. Aber wie gesagt: ich kennen keine Implementierung die das macht. Falls jemand eine kennt: bitte melden

@ hustbaer: Danke für die Erläuterungen. Den Punkt habe ich sogar auch noch gesehen, aber mir nichts weiter dabei gedacht. Aber eigentlich ist es logisch... Normalerweise versuche ich auch, globale Variablen und frühzeitige Initialisierung genau wegen solcher Dinge zu vermeiden. Aber ab und zu ist das Ganze einfach zu praktisch

Allerdings könnte man manche Fälle auch lösen, indem man bei der ersten Verwendung einer Funktion die Initialisierung vornimmt (über eine funktionslokale static -Variable). Vielleicht sollte ich mir das überlegen... Ein static bool in einer Funktion hat wahrscheinlich nicht einmal ein verstecktes if (__initialized) , oder? (Bin mir gerade nicht sicher, ob das auch unter die normale static storage duration geht oder wieder zu irgendeinem Spezialfall gehört)

Verwende gleich das "Meyers Singleton", das ist wenigstens mit GCC thread-safe.
Bzw. nimm folgenden Code (der vom Prinzip her das selbe macht wie das "Meyers Singleton", nur ohne Singleton *g*)

int MyInitFunction()
{
   // ...
   return 42;
}

void MyPublicFunction()
{
    static int const s_myInitDummy = MyInitFunction();
    // ...
}

s_myInitDummy muss hier ein "if (!initialized)" vom Compiler verpasst bekommen, sonst würde es ja immer wieder überschrieben, und das erlaubt der Standard nicht. Dadurch sparst du dir selbst das entsprechende "if" zu schreiben, und bekommst von GCC wie schon gesagt auch threadsicheren Code geschenkt.

Ansonsten kann man boost::call_once verwenden um es unabhängig vom Compiler thread-safe zu machen.

Aber davon abgesehen

Allerdings könnte man manche Fälle auch lösen, indem man bei der ersten Verwendung einer Funktion die Initialisierung vornimmt (über eine funktionslokale static-Variable). Vielleicht sollte ich mir das überlegen...

Wenn das geht, dann ist ja alles wunderbar.
Der hier diskutierte Workaround ist vor allem für Fälle gedacht, wo das nicht funktioniert, weil man Dinge vor Programmstart erledigen möchte. z.B. das Registrieren von Plugins/Modulen.

Bzw. allgemein Fälle, wo man die Nebeneffekte braucht, bevor eine Funktion aufgerufen wird deren Code man anfassen will/kann/darf.

Allerdings wüsste ich nicht wozu man so ein static bool jetzt bräuchte. Ausser um seinen Code thread-unsafe zu machen.
[...]
s_myInitDummy muss hier ein "if (!initialized)" vom Compiler verpasst bekommen, sonst würde es ja immer wieder überschrieben, und das erlaubt der Standard nicht. Dadurch sparst du dir selbst das entsprechende "if" zu schreiben, und bekommst von GCC wie schon gesagt auch threadsicheren Code geschenkt.

Ich meinte genau sowas wie s_myIntDummy , aber halt ein bool (spielt ja keine Rolle). Ok, jetzt sehe ich auch, dass bool im dem Zusammenhang verwirrend ist, sorry. Ist so eine static -Konstante auf gcc nun threadsafe oder nicht? Denn irgendwie sehen deine Aussagen für mich wie ein Widerspruch aus

Konkret brauch ich das für einen Zufallsgenerator, dessen Seed beim Starten automatisch gesetzt werden soll. Da wäre Threadsicherheit wahrscheinlich nicht schlecht. Allerdings müsste ich dann auch noch einiges mehr threadsicher machen...

Wenn du es nicht selbst schreibst, sondern eine function-local static Variable verwendest, dann macht der Compiler es für dich. Und GCC macht es threadsafe. MSVC nicht.

Was der aktuelle C++0x Draft dazu sagt weiss ich nicht sicher. Ich glaube der sieht das so wie GCC es sieht, nämlich dass es threadsafe sein muss.

Konkret brauch ich das für einen Zufallsgenerator, dessen Seed beim Starten automatisch gesetzt werden soll. Da wäre Threadsicherheit wahrscheinlich nicht schlecht.

Zufallsgenerator mach ich immer als Instanzen, keine globalen Funktionen. Daher gibt's das Problem auch nicht.

Ansonsten ist thread-local Storage angesagt. Sonst kann ein Thread durch das Ziehen von Zahlen aus dem RNG die Sequenz die ein anderer Thread bekommt beeinflussen. -> nicht gut.

p.S.: und mit thread-local Storage ist thread-safety bei der Initialisierung dann wieder kein Problem, da je eh jeder Thread seine eigenen Variablen hat.

Zufallsgenerator mach ich immer als Instanzen, keine globalen Funktionen. Daher gibt's das Problem auch nicht.

Ja, wäre sicher flexibler, gerade wenn man an verschiedenen Orten voneinander unabhängige Zufallszahlen haben will. Allerdings brauch ich oftmals nur kurz in einem temporären Ausdruck eine Zufallszahl, dafür immer vorher ein Objekt anzulegen ist unpraktisch und liefert auch schlechte Zufallszahlen, wenn er erst gerade mit dem Seed initialisiert wurde. Oder man hätte halt zusätzlich eine globale Instanz, wobei dann wieder das Problem auftritt.

Wie machst du das, findest du immer einen genügend grossen Kontext, in dem du so ein RNG-Objekt anlegst, oder hast du dann auch häufig lokale "Wegwerf-Objekte"?

Allerdings brauch ich oftmals nur kurz in einem temporären Ausdruck eine Zufallszahl, dafür immer vorher ein Objekt anzulegen ist unpraktisch und liefert auch schlechte Zufallszahlen, wenn er erst gerade mit dem Seed initialisiert wurde.

Ja, unpraktisch. Ich habe gerne ein globales Objekt.

Aber daß der frisch geseedete Zufallszahlengwenerator schlechten Zufall liefert, sehe ich jetzt noch nicht.

int getSeed(){
   static int seed=time(0);//beim ersten mal uhrzeit lesen
   ++seed;//bei mehreren aufrufen unique machen
//nicht schlampig verwürfeln, dazu ist der Zufallszahlengenerator besser geeignet
   return seed;
}

Random::Random(){
   x=getSeed();
   this->rand();//die angekündigte initiale Verwürfelung
}
unsigned int Random::rand(){
  x=(x*17+5)%1000;//oder bessere Formel!
  return x;
}

Meine Überlegung ist halt, dass Zufallszahlengeneratoren ihre Stärken (z.B. Einhalten einer gegebenen Verteilung, geringe Korrelation) vor allem dann ausspielen, wenn eine grössere Sequenz eingesetzt wird. Einzelne, frisch geseedete Zufallszahlen müssen diese Eigenschaften ja nicht zwingend erfüllen.

Ich erwarte, daß die geringe Korrelation zwischen zwei aufeinanderfolgenden Zahlen zu erwarten ist. Deswegen mache ich nur ein rand() im Konstruktor. Ich verlasse mich darauf, daß der Generator recht ordentlich ist, und halte rand(); für nicht schlechter als rand();rand();rand();. Höchstens besser.

Aber hast recht, die nachgewiesenen Qualitäten des Generators sind bei meiner angedachten Benutzungsart nicht mehr da. Zum Beispiel die unglaubliche Periodenlänge des Mersenne Twisters muß ja weg sein.

Wie machst du das, findest du immer einen genügend grossen Kontext, in dem du so ein RNG-Objekt anlegst

Genau das.
Wobei das in meinen Projekten immer recht einfach war, weil nur an wenigen Stellen wirklich Zufallszahlen gebraucht wurden. Dafür hab' ich schon manchmal verschiedene unabhängige Sequenzen gebraucht, daher würde ich auch nicht (ausschliesslich) mit einem globalen Generator arbeiten wollen.

oder hast du dann auch häufig lokale "Wegwerf-Objekte"?

Nö, das wäre mit den Generatoren die wir verwenden (Mersenne Twister) und mit der Art wie wir den Seed holen (CryptGenRandom) auch VIEL zu teuer.

void Func()
{
    Randomizer r;
    Use(r.Random());
}

nicht lieber

void Func()
{
    static Randomizer r;
    Use(r.Random());
}

einsetzen würde (von Threadsicherheit mal abgesehen)? Denn auch wenn man mehrere unabhängige Randomizers jeweils am Anfang verwürfelt, ist die aus verschiedenen Randomizer -Aufrufen resultierende Gesamtsequenz unschön. Es könnte ja sein, dass z.B. immer nur jede Sekunde so ein Aufruf stattfindet, und abhängig von der Qualität des Seeders eine unregelmässige Verteilung oder so auftritt.

Man könnte zwar argumentieren, dass in so einem Fall ein einzelner Randomizer benutzt werden sollte (wie im Code mit static ), aber dann hat man eben wieder einen Vorteil weniger durch die unabhängigen Objekte.

void Foo::Func()
{
   Use(m_rng.Get());
}

// oder
template <class G>
void Func(G& rng)
{
   Use(rng.Get());
}

// oder
void Func(AbstractRng& rng)
{
   Use(rng.Get());
}

?