c++ static POD initialization

I have a single instance of a simple POD

a.hpp

class A {
    struct Zzz {
        A*  m_aPtr;
        int m_val;
    }

    static Zzz s_zzz;
};

a.cpp

A::Zzz A::s_zzz;

I expect that both s_zzz.m_开发者_JAVA百科aPtr and s_zzz.m_val will be initialized to zeros before any other static initialization in any other compilation unit and it is guaranteed by the language itself. Am I right about it?

Usually I provide default constructors for the structs. Say

A::Zzz::Zzz() :
 m_aPtr(0),
 m_val(0)
{
}

Will it create initialization order problem or introduce compiler dependencies?

At least in C++0x, you can rely on all zero-initialization being performed before any other initialization code runs.

From the C++0x FCD, section [basic.start.init]

Variables with static storage duration (3.7.1) or thread storage duration (3.7.2) shall be zero-initialized (8.5) before any other initialization takes place.

If you're considering using this variable from other initialization code, then an explicit constructor would be a big mistake, as it would run sometime mixed in with other initialization code, and overwrite whatever changes have already been made by other initializers.

I expect that both s_zzz.m_aPtr and s_zzz.m_val will be initialized to zeros before any other static initialization in any other compilation unit and it is guaranteed by the language itself.

It will be zero-initialized, since it's a static lifetime variable at namespace scope.

That zero-initialization happens before any dynamic initialization (an example of dynamic initializatin is when you some explicit initialization, or the class has a constructor).

The order of zero-initialization between different translation units is not defined, but there's not any way to detect it or rely on it since it happens before anything else, so it doesn't matter.

Re your point 2, it's rather unclear what you're asking about.

But for your static lifetime object, the effect is just that it's first zero-initialized, and then during dynamic initialization your constructor is used to zero it again (although the compiler might be smart enough to optimize away that redundant extra initialization).

Cheers & hth.,

ERRATA: Ben Voigt has provided a convincing example that the last paragraph above is wrong. So please disregard. The presence of the constructor means that the object can be dynamically initialized at some point before, between or after operations that change it, causing rather unpredictable results…

1. There are no guarantees about initialization order of statics between compilation units (see http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.14).

2. If it has a constructor, it will no longer be a POD, unfortunately.

1. Static data is always initialised to zero.
2. No it shouldn't introduce any initialisation problems.

When the application is loaded into memory, the static area is initialised to zero. This is before any code starts to execute.