Statische variable nicht initialisiert

Ich habe ein seltsames problem mit einer statischen variable, die offensichtlich nicht initialisiert ist, wie es sein sollte.

Ich habe ein riesiges Projekt, das läuft mit Windows und Linux. Da die Linux-Entwickler dieses problem nicht hat, würde ich vorschlagen, dass diese Art von WLAN-Visual-Studio-Zeug.

Header-Datei

class MyClass
{
    //some other stuff here
    ...
    private:
        static AnotherClass* const Default_;
};

CPP-Datei

AnotherClass* const MyClass::Default_(new AnotherClass(""));
MyClass(AnotherClass* const var)
{
    assert(Default_);
    ...
}

Problem ist, dass Default_ist immer NULL. Ich habe auch versucht, einen Haltepunkt bei der Initialisierung der Variablen, aber ich kann es nicht fassen.

Gibt es ein ähnliches problem in einer anderen Klasse.

CPP-Datei

std::string const MyClass::MyString_ ("someText");
MyClass::MyClass()
{
    assert(MyString_ != "");
    ...
}

In diesem Fall MyString_ist immer leer. Damit nicht wieder initialisiert.

Hat jemand eine Idee dazu? Dies ist ein Visual Studio-Einstellungen problem?

Cheers Simon

Edit:

Stieß ich auch auf die statische Initialisierung Fiasko. Aber ich bin mir nicht sicher, ob das könnte das problem sein, da gibt es keine Probleme mit dem Linux-compiler. Sollte das nicht der compiler in der gleichen Weise reagieren in diesem Fall?

Versuchen Sie, erstellen ein neues Projekt von Grund auf und sehen, wenn es passiert, gibt es auch
Sorry, kann das nicht tun. Als ich sagte, dass es ein wirklich riesiges Projekt.
Ich nehme an, das erste Beispiel war ein Tippfehler und sollte AnotherClass* const MyClass::Default_(new AnotherClass(""));
Man könnte noch versuchen, indem Sie ein neues, leeres test-Projekt mit einer statischen member und sehen, ob es richtig initialisiert wird, aber...
Ist dieser code in einer DLL?
Keine DLL - @Ashley: Ok, ich habe eine neue Projekt ähnlich wie das Amt des sbi und es funktioniert auch!?
Ist der code in einer statischen Bibliothek? Anschließend führen Sie in Probleme, wenn die Klasse MyClass (gerade die compilation unit) wird nicht verwiesen wird, indem Sie das hing Programm. Der linker wird dann nicht das erstellen von statischen Initialisierungs-code für die variable.
Es ist eine statische Bibliothek...

InformationsquelleAutor Simon Linder | 2010-04-27

c++static variables visual-studio-2008

6

Ich schlage vor, Sie verwenden statischen member-Funktion static-variable und nicht die variable selbst:
```
class MyClass
{
    //some other stuff here
    ...
    private:
        static AnotherClass* const getAnotherClass();
};

AnotherClass *const MyClass::getAnotherClass()
{
    static AnotherClass *const p = new AnotherClass("");
    return(p);
}
```
Der standard garantiert, dass p einmal initialisiert, wenn die Funktion das erste mal aufgerufen, so erhalten Sie immer richtig initialisiert Objekt (es sei denn, Sie haben bereits erschöpft, Speicher-oder Sie-Konstruktor warf).

Bitte beachten Sie, dass dies möglicherweise oder möglicherweise nicht thread-sicher (hängt von Ihrem compiler wirklich).

Ist und noch ein Hinweis - jetzt haben Sie, um zu Leben mit "memory leak" wie ist es wirklich unmöglich, zu entscheiden, wenn um das Objekt zu zerstören und Sie haben KEINE MÖGLICHKEIT zum zurücksetzen von p auf NULL.
- Es ist von schlechtem Geschmack zu verwenden, die einen Zeiger in diesem Fall. Ein schlichtes Instanziierung gefolgt von der Rückgabe einer Referenz wäre viel besser. Nachdem alle, ist nicht ein * const das semantische äquivalent zu & einmal haben Sie entfernt die NULL-Möglichkeit ?
- Ich bin einfach folgenden code gegeben. Für Ihren Kommentar - Sie sind wahrscheinlich Recht, aber es hängt wirklich davon ab, was AnotherClass tut (es kann zum Beispiel Essen Sie alle den Raum in Ihrem Daten-segment gibt es also nichts mehr übrig für andere globals).
- Ich bin damit einverstanden, dass es notwendig sein kann, um die Verwendung der heap, um Sie nicht zu sättigen, die Daten-segment oder die stack (ich Art wollen für Go hier...) aber es sollte reserviert werden, denke ich, auf Besondere Situationen (große Objekte) und verschoben, bis notwendig.
- Noch ein Hinweis hier auf der statischen AnotherClass versus statische Zeiger auf AnotherClass: wenn Sie mit dem Zeiger, das Objekt ist sehr wahrscheinlich weiterhin für das Programm Leben und der Destruktor wahrscheinlich nicht genannt werden, es sei denn, zu kümmern. Dies kann ein problem sein, wenn das Objekt enthält system-Ressourcen, die müssen Sie manuell frei. Für das statische Objekt der Destruktor aufgerufen WIRD, aber Sie haben keine Ahnung und keine Kontrolle, wenn es passiert, und dies kann dazu führen Sie statische Zerstörung, um ein Fiasko.
InformationsquelleAutor Tomek
4

In diesem Fall während der Initialisierung einige andere statische Variablen, die Sie möglicherweise sehen werden, sind die statische Initialisierung Fiasko.
- Dies ist ein Visual Studio-compiler problem? Oder ein Allgemeines problem?
- Das ist ein Allgemeines problem.
- So ist es nicht mein problem hier, da die Linux-Entwickler nicht haben ein ähnliches problem...
- Grundsätzlich, wenn Sie die unterschiedliche Zusammenstellung Einheiten/Objekt-Dateien ist es nicht garantiert, dass diese initialisiert werden, die in einer bestimmten Reihenfolge. Also, wenn statische Variablen in einer Objekt-Datei initialisiert werden, zuerst, und Sie versuchen Sie eine andere, statische Variablen, die noch nicht initialisiert wurde, gibt es Probleme. Die Reihenfolge ist undefiniert, so dass es möglicherweise oder möglicherweise nicht "Arbeit" mit einem anderen compiler und dies könnte sich ändern, sobald Sie Dateien zum Projekt hinzufügen oder ändern etwas anderes. Da der init-Reihenfolge ist im Grunde zufällig das problem könnte sehr gut sein, da auch wenn es nicht zeigen, bis in einigen bestimmten build.
InformationsquelleAutor sth
3

Sollte nicht der compiler in der gleichen Weise reagieren in diesem Fall?

Nicht. Wie ich es verstehe, ist die Initialisierung in der Reihenfolge der individuellen Zusammenstellung Einheiten nicht definiert. Also die Linux-Entwickler einfach nur Glück. Heute. Morgen, wer weiß?

InformationsquelleAutor Roddy
0

Funktioniert Auf Meiner Maschine(TM):
```
#include <iostream>
#include <cassert>

class AnotherClass
{
public:
    AnotherClass(const char*) {}
};

class MyClass
{
public:
    MyClass(AnotherClass* const var);
private:
    static AnotherClass* const Default_;
};

AnotherClass* const MyClass::Default_(new AnotherClass(""));

MyClass::MyClass(AnotherClass* const var)
{
    assert(Default_);
    std::cout << "Worked!\n";
}

int main()
{
    MyClass tester(NULL);
    return 0;
}
```
Ich nehme an, das problem ist, dass MyClass::MyClass() nennt als eine weitere statische variable Konstruktor. Die Initialisierung von statischen Variablen, die nicht immer auftreten, in der Reihenfolge, die Sie möchten, dass es.
- Aber in seinem zweiten Beispiel erinnerte er sich an den MyClass:: so dass es wahrscheinlich nur ein Schreibfehler in der Frage.
- Ja, es sollte und es ist nur ein Tippfehler, aber danke.
- Dein Beispiel funktioniert auch bei mir.
- Sie erwähnten, dass der Aufruf kann in einem anderen static-Variablen Konstruktor. Ich habe noch um dies zu überprüfen. Aber sollte nicht dann das gleiche problem mit dem Linux-compiler?
- Ich habe das ganze stack-trace und nichts finden können statisch...
- Wenn das eine statische Initialisierung Problem, dann ist das Ergebnis undefined. Das bedeutet, dass es funktionieren könnte, in einem Fall, würde aber nicht in einem anderen. Wenn Sie nicht denken, dies ist eine statische Initialisierung Problem, dann ist die einzige Sache, die ich denken kann, ist eine Kopie des Quellcodes, und Stück für Stück entfernen Sie einige davon, so dass das problem weiterhin Auftritt, bis Sie unten zu einem kleinen Beispiel, dass reproduziert das Problem. in der Regel ist das problem gefunden, dass Art und Weise. Wenn nicht, poste es hier, wenn es klein genug ist, so dass andere einen Blick darauf werfen.
InformationsquelleAutor sbi

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.