struct A {
   A() { Startup(); }
   ~A() { Cleanup(); }
   static A a;
};

A A::a;

So eine ähnliche Idee hatte ich auch. Allerdings nutze ich (und boost auch) Exceptions als Fehlermechanismus, und asio benutzt eine Exception innerhalb des Konstruktors.
Das führt doch immer zu std::abort(), da die Exception nicht gefangen werden kann. Ist das ein Fehler von asio o. nur meine Unwissenheit?

> Warum weichst du denn nicht auf einen anderen Fehlerbehandlungsmechanismus aus?

Ich bin da leider etwas unkreativ, weil mir einfach keiner einfällt, der funktionieren könnte:

• Exceptions können natürlich nicht klappen (in <boost/asio/detail/winsock_init.hpp> wird's trotzdem getan)
• Return-Codes kann ich nicht auswerten, da der User nichts aufruft

Mir viele höchstens soetwas hässliches ein:

struct A {
   A() { 
     if(Startup())
        initialised = true;
   }

   ~A() { 
     if(Cleanup() == false) 
        // Was jetzt?
   }

   static bool initialised;
   static A a;
};

bool A::initialised = false;
A A::a;

int main() {
   // Hässlich
   if(!A::initialised)
      throw std::exception("error");
   // Nur kann ich jetzt nicht prüfen, ob Cleanup klappt)
}

Exception innerhalb des Konstruktors.
Das führt doch immer zu std::abort(), da die Exception nicht gefangen werden kann.

Meinst du nicht eher eine Exception innerhalb des Destruktors. Innerhalb des Konstruktors sind Exceptions doch kein Problem.

> Innerhalb des Konstruktors sind Exceptions doch kein Problem.

Gewöhnlich nicht, nein. Aber hier schon. Schau mal auf Zeile 17. Das ist ein Konstruktoraufruf. Nur, der findet im globalen Scope statt (!).
D.h., dass noch vor main() Code ausgeführt wird. Wenn ich in diesem Code eine Exception werfe, kann sie nicht gefangen werden, und das endet immer in std::abort().

a) du lässt es dabei, dass abort() aufgerufen wird - wenn es etwas sehr wichtiges ist, ohne das das Programm eh nicht laufen kann, dann reichts, da noch ne Fehlermeldung auszuspucken (function scope try/catch um den Ctor) und dann das Programm ins abort laufen zu lassen.

b) Du rufst den Ctor später auf - die Methoden, die sich drauf verlassen müssen, dass Startup() bereits aufgerufen wurde, rufen eine Statische Methode von A auf, die die Initialisierung übernimmt:

class A
{
  A() {Startup();}
  ~A() {Cleanup()}

public:
  static void initialize() 
  {
    static A const a;
  }
};

void some_foo_that_needs_startup()
{
  A::initialize();
  //do the foo
}

So wird die Exception erst geworfen, wenn das erste mal eine Funktion aufgerufen wird, die initialize() aufruft. Alle weiteren Aufrufe von initialize() machen nichts mehr. Abgeräumt wird das Objekt wie gehabt nach Beendigung der main().
PS: über Threadsafety hab ich mir im Moment keine Gedanken gemacht...

> PS: über Threadsafety hab ich mir im Moment keine Gedanken gemacht...

Das spielt zum Glück an dem Punkt keine Rolle, da die API-Funktion threadsafe ist.

Danke

> PS: über Threadsafety hab ich mir im Moment keine Gedanken gemacht...

Das spielt zum Glück an dem Punkt keine Rolle, da die API-Funktion threadsafe ist.

Danke

Ob die API Funktion thread-safe ist oder nicht, darum geht's nicht unbedingt.
Verwende einfach boost::call_once um die Init-Funktion aufzurufen.

> darum geht's nicht unbedingt.

Worum denn dann? Was kann denn schon passieren?

EDIT: ich halte die Frage "was kann denn schon passieren" übrigens für den komplett falschen Ansatz, um nicht zu sagen: für dumm und gefährlich.

> In diesem einfachen Beispiel vermutlich nicht viel.

Ich behaupte mal: nichts.

> "Korrekt" ist es IMO dennoch nicht.

Wieso?

> ich halte die Frage "was kann denn schon passieren" übrigens für den komplett falschen Ansatz

Ich programmiere exceptionsicher - aber hier kann einfach nichts passieren.

> In diesem einfachen Beispiel vermutlich nicht viel.

Ich behaupte mal: nichts.

Die offensichtliche Variante ist, dass es passieren könnte, dass der Konstruktor von A 2x concurrent ausgeführt wird. OK, die Funktion die im Konstruktor ausgefürht wird ist thread-safe, soll sein. Aber wer sagt dass der Compiler für die Initialisierung von statischen Variablen Coder erzeugt der thread-safe ist? Der Standard schreibt das nicht vor.

Je nachdem wie der Compiler die Initialisierung von statics implementiert (und auf welcher CPU das ganze läuft), könnte es auch passieren, dass A::a gar nicht initialisiert wird, wenn A::initialize gleichzeitig in zwei Threads ausgeführt wird.

Daher ist es nicht korrekt. So einfach ist das.