Hat jemand eine Idee wie das Zustande kommt?

Ich habe auch mal testweise einfach das "const" bei der Konstante weggelassen, das ändert auch nichts. Es mag ja sein das man Konstanten nicht auf diese weise initialisieren soll, aber warum läßt der Compiler das dann zu?

CConfigNode.h:

class CConfigNode {
public:
    // ...
    static const uint16 CN_ID_FILEROOT;  // hier ist die Konstante
    // ...
};

CConfigNode.cpp:

#include "CConfigNode.h"
// ...
// initialisierung der Konstante
const uint16 CConfigNode::CN_ID_FILEROOT = CConfigNameTable::getInstance().getIdFromName("fileroot");
// ...

CConfigNameTable.h:

// das Singleton
class CConfigNameTable {
public:
    // ...
    static const CConfigNameTable& getInstance() { return instance; }

    uint16 getIdFromName(const std::string& sName) const;
private:
    // ...
    static CConfigNameTable instance;
};

Dank im voraus,
Coolcat

P.S.:
Falls wichtig:
Compiler: GCC 4.1.1 / FC5 Linux / Kernel: 2.6.17-1.2187_FC5

CConfigNameTable.cpp

CConfigNameTable CConfigNameTable::instance = CConfigNameTable();

Eine statische Memberfunktion kann doch ohne vorhandenes Objekt ausgeführt werden.

Klar, aber getIdFromName() ist nicht statisch.

Coolcat

class CConfigNameTable {
public:
    static const CConfigNameTable& getInstance() {
        static CConfigNameTable instance = CConfigNameTable();
        return instance;
    }
    // ...
};

das funktioniert.

Ich verstehe allerdings immer noch nicht warum das andere nicht funktionierte.

Coolcat

Hm, hab es auf deinen Rat hin jetzt so gelöst:

So reicht auch, sonst hast Du eine unerwünschte Copyconstruction aus einem Temporary (oder?!). Letzteres würde aber auch verhindert wenn Du den Konstruktor des Singletons private machen würdest.

class CConfigNameTable {
public:
    static const CConfigNameTable& getInstance() {
        static CConfigNameTable instance;
        return instance;
    }
};

Ich verstehe allerdings immer noch nicht warum das andere nicht funktionierte.

Weil die Initialisierungsreihenfolge von statischen Objekten auf File-Scope nicht garantiert ist. Will heissen es könnte sein dass die statischen Member von CConfigNode initialisiert werden bevor das statische Member instance von CConfigNameTable initialisiert wurde. Statische Objekte in Funktions-Scope werden hingegen beim ersten Aufruf der Funktion initialisiert, und Du hast so eine definierte Initialisierungsreihenfolge.

So reicht auch, sonst hast Du eine unerwünschte Copyconstruction aus einem Temporary (oder?!)

Ich denke doch das der Compiler schlau genug ist das zu erkennen. Naja, ich habs trotzdem mal geändert. :p

Will heissen es könnte sein dass die statischen Member von CConfigNode initialisiert werden bevor das statische Member instance von CConfigNameTable initialisiert wurde.

Ok, das reicht mir

thx @ all

Coolcat