//Header.hpp
namespace 
{
  class Type
  {
    private:
    public:
      Type();
      ~Type();
  };
  extern Type Obj;
}
//Wie Header.cpp aussieht könnt ihr euch vorstellen
//Main.cpp
#include "Header.hpp"
//Hier könnten ein paar Objekte stehen
int main()
{
//Hier auch
}

Wird hier garantiert, dass der Konstruktor von " Obj " als erster und der Destruktor als letzter aufgerufen werden (also vor allen anderen Konstruktoren und nach allen anderen Destruktoren)?

MfG, EOutOfResources

EDIT: Für die Frage "wieso": C-Library (one more time)

Und allgemein ist das natürlich schlechtes Design, wenn es bei dir auf die Initialisierungsreihenfolge von globalen Objekten ankommt, aber das ist dir sicherlich selber klar.

Und allgemein ist das natürlich schlechtes Design, wenn es bei dir auf die Initialisierungsreihenfolge von globalen Objekten ankommt, aber das ist dir sicherlich selber klar.

Das kannst du mal OpenAL sagen...

Mit "extern" hast du ein Problem, da [unnamed-namespace-in-main.cpp]::Obj nirgends definiert wird, bloss deklariert. [unnamed-namespace-in-header.cpp]::Obj wird zwar vermutlich definiert, nur das ist ein anderes Objekt, mit einem anderen Typ, und aus main.cpp nicht ansprechbar.

Angenomman es war ein benannter Namespace gemeint, dann ist die Reihenfolge undefiniert.

Einzige Lösung dir mir jetzt einfällt, ist, ein Singleton zu verwenden, ala so:

//Header.hpp
namespace Foo // muss wie schon gesagt nen Namen haben
{
  class Type
  {
    private:
      Type();
      ~Type();
    public:
      friend Type& GetInstance()
      {
          static Type Obj;
          return Obj;
      }
  };
}

namespace // diesmal wirklich unnamed, damit's in jeder Translation-Unit eine eigene (unabhängige) Referenz "Obj" gibt
{
    Foo::Type& Obj = Foo::Type::GetInstance();
}

// Rest wie in deinem Beispiel

Bzw. es muss natürlich "Type" nicht gleich ein Singleton sein. Wichtig ist, dass jede TU selbst "Type::GetInstance()" aufruft um ein Objekt zu initialisieren das in dieser TU definiert wird (=die "Obj" Referenz im unnamed Namespace).

Beim ersten Aufruf von "Type::GetInstance()" wird dann das "static local" Objekt initialisiert, und das passiert dann garantiertermassen vor der Initialisierung von Dingen die nach dem #include "header.hpp" definiert sind.

Eventuell solltest du mal erklären, was genau du mit der gesamten Kontruktion eigentlich bewirken willst.

Eventuell solltest du mal erklären, was genau du mit der gesamten Kontruktion eigentlich bewirken willst.

" Type " ist eine Klasse die im Konstruktor eine Funktion aufruft und im Destruktor ebenfalls eine Funktion aufruft. Das Ergebnis der ersten Funktion wird gespeichert. So ungefähr sieht das dann aus:
Type.hpp:

//Jaja, Include-Guards. Hab ich im Original...
namespace
{
  class Type
  {
    private:
      void* Handle;
      Type(const Type&);
      Type& operator= (const Type&) const;
    public:
      Type();
      ~Type();
      void* Get();
  };
  extern Type Obj;
}

Type.cpp:

#include "Type.hpp"
Type::Type()
{
  this->Handle = Func_Begin();
}
Type::~Type()
{
  Func_End(this->Handle);
}
void* Type::Get()
{
  return this->Handle;
}
Type Obj;

Der Konstruktor und der Destruktor sind im Original noch ein wenig praller, damit das Ganze ausnahmesicher ist.
Noch konkreter:
Die Funktion " Func_Begin " gibt ein Handle auf ein Device zurück (nötig für alle anderen Dinge der Lib) und die Funktion " Func_End " zerstört das Handle wieder.

EDIT: Was ich mir gedacht habe:
Ich wusste, dass ich einen Funktionsaufruf zu Beginn benötigte -> Gedanke an Konstuktor -> Klasse, von der eine Instanz existiert -> Gleichzeitig auch Speicher des Handles

Können denn eigentlich mehrere Objekte deiner Klasse existieren?

Rein von der Logik her, nein. Aber ich hab es noch nicht verboten, da ich ja der Einzige bin, der Zugriff auf die Klasse hat.

CStoll schrieb:

In dem Fall kannst du die Geschichte mit dem anonymen Namensraum und der (doch nicht so) globalen Variablen verzichten und dort wo benötigt ein Objekt anlegen.

Daran habe ich auch gedacht, aber ich weis nicht, wie es mit der Performance der Funktion aussieht (werde ich mal testen).

CStoll schrieb:

Andernfalls dürfte die Singleton-Konstruktion, die hustbär vorgeschlagen hat, die stabilere Lösung sein.

Werde ich auch mal testen.

CStoll schrieb:

Können denn eigentlich mehrere Objekte deiner Klasse existieren?

Rein von der Logik her, nein. Aber ich hab es noch nicht verboten, da ich ja der Einzige bin, der Zugriff auf die Klasse hat.

Solche internen Details packt man dan aber nicht in Header, die überall offen im Quelltext untergebracht werden. Wenn diese Klasse nur dazu da ist, dein globales Device-Handle zu verwalten, kannst du sie auch in der ÜE lokal definieren, die mit diesem Handle arbeiten will.

// header.hpp

namespace Detail
{
int CallMeOnceBeforeDoingStuff();
}

namespace
{
int const g_initHelperDummy = CallMeOnceBeforeDoingStuff();
}

// ---------------------------------------------------------------

// header.cpp

namespace Detail
{

boost::once_flag g_onceFlag = BOOST_ONCE_INIT;

void CallMeOnceBeforeDoingStuffImpl()
{
// do whatever needs to be done
}

int CallMeOnceBeforeDoingStuff()
{
    boost::call_once(CallMeOnceBeforeDoingStuffImpl, g_onceFlag);
}

}

Jetzt bin ich verwirrt.

Das glaube ich.

EOutOfResources schrieb:

Das extern brauch ich wegen der ODR (nicht?).

In diesem Fall verwendest Du es, um eine Definition in eine Deklaration zu verwandeln. So oder so hat das Ding eine externe Bindung. Nur ist der Name unaussprechbar und ÜE-spezifisch wegen des anonymen Namensraums.

EOutOfResources schrieb:

Und ich dachte, der anonyme Namensbereich (bzw. sein Inhalt) sei nur für die Übersetzungseinheit ansprechbar, die ihn auch definiert. Deshalb habe ich die Klasse " Type " in den anonymen Namensbereich getan (dass der User sie nicht anfassen kann).

Diese Logik kann ich nicht nachvollziehen. Ich schätze, dass Du da noch ein paar Sachen falsch verstehst.

Wegen des anonymen Namensraums gibt es in jeder ÜE, die diese Include-Datei einbindet, einen eigenen Typ "Type". Und nur der "Type" innerhalb von Type.cpp wird als einziger "ausdefiniert" (also Konstruktor & co). Auch die reine Deklaration von Obj im anonymen Namensraum ist sinnfrei, da du es nicht in einer anderen ÜE definieren kannst.