Question: I've got a strange problem with a static variable that is obviously not initialized as it should be.

I have a huge project that runs with Windows and Linux. As the Linux developer doesn't have this problem I would suggest that this is some kind of wired Visual Studio stuff.

Header file

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

```

CPP file

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

```

Problem is that `Default_`is always `NULL`. I also tried a breakpoint at the initialization of that variable but I cannot catch it.

There is a similar problem in another class.

CPP file

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

```

In this case `MyString_`is always empty. So again not initialized.

Does anyone have an idea about that? Is this a Visual Studio settings problem?

Cheers Simon

**Edit:**

I also came across the static initialization fiasco. But I'm not sure if that could be the problem because there are no problems with the Linux compiler. Shouldn't the compiler react the same way in this case?

Answer: 
I suggest you use static member function with static variable and not static variable itself:

```
class MyClass
{
    // some other stuff here
    ...
    private:
        static AnotherClass* const getAnotherClass();
};

AnotherClass *const MyClass::getAnotherClass()
{
    static AnotherClass *const p = new AnotherClass("");
    return(p);
}

```

The standard guarantees that p is initialized once when the function is called for the first time, so you will always get properly initialized object (unless you've already exhausted memory or you constructor threw).

Please note - this may or may not be thread safe (depends on your compiler really).

And yet another note - now you have to live with "memory leak" as it is really next to impossible to decide when to destroy the object and you have NO WAY to reset p to NULL.
> 
> Shouldn't the compiler react the same way in this case?
> 
> 
> 

No. As I understand it, the initialization order of individual compilation units is UNDEFINED. So the Linux developer just got lucky. Today. Tomorrow, who knows?