When are C++ implicit types initialized to 0?

Question

I grew some doubts after discussing this with colleagues...

As the title asks, when can it be assumed that built-in types will be initialized to 0 instead of an unknown value?

Do the rules vary among the c++ standards?

Answer 1

The full rules are in [dcl.init] (C++11). To summarize: when no initialiser is provided in a declaration, the entity is so-called default-initialised. For class types, this means the default constructor is called. For non-class types, this means no initialisation is performed.

However, [dcl.init] §9 states: "Every object of static storage duration is zero-initialized at program startup before any other initialization takes place."

This means that static-duration variables (such as namespace-scope variables) of non-class type are zero-initialised. Other objects of non-class types (such as local variables) are not initialised.

Answer 2

Rather than answering the exact question you post, which has been answered before: only POD objects with static storage will be initialized to 0 automatically, I will try to provide pieces of code to get the compiler to initialize the members for you:

struct POD {
   int    a;
   double b; //...
};
// namespace level:
POD p;
void f() {
   POD n1;                  // uninitialized
   POD p1 = {};
   POD p2 = POD();
   POD* n2 = new POD;       // uninitialized
   POD* pp1 = new POD();
   delete n2; delete pp1;
}

In the examples above only those marked with 'uninitialized' won't be initiazed. Note that this is with respect to what the standard mandates, your mileage will vary with different compilers. In particular VS has some issues with T t = T(); and T* p = new T()' in some scenarios (IIRC when the type T is not a POD, but does not have a user provided default constructor the compiler will fail to initialize the POD subobjects:

struct T {
   std::string s;
   int         i;
};
void f() {
   T t = T();    // t.i == 0 according to the standard
}

Answer 3

Theory:

According to both C++98 and C++03 standards:

3.6.2 Initialization of non-local objects, §1:

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

3.7.1 Static storage duration, §1:

All objects which neither have dynamic storage duration nor are local have static storage duration.

3.7.1 Static storage duration, §3:

The keyword static can be used to declare a local variable with static storage duration.

And also 8.5 Initializers, §6:

Every object of static storage duration shall be zero-initialized at program startup before any other initialization takes place.

This is the same in both standards. The only difference is in formulation of C++98's 8.5 §6:

The memory occupied by any object of static storage duration shall be zero-initialized at program startup before any other initialization takes place.

---

Example:

Here's the example, where x and y and have static storage duration, thus standard guarantees that both of them will be zero-initialized at program startup. Note that there are also POD objects a and b declared in the same manner, thus having static storage duration, which means that their members (i and d) will be zero-initialized as well:

struct POD {
    int i;
    double d;
};

int x;
POD a;

int foo() {
    static int y;
    return y;
}

int main() {
    static POD b;
    std::cout << "x   = " << x      << std::endl;
    std::cout << "y   = " << foo()  << std::endl;
    std::cout << "a.i = " << a.i    << std::endl;
    std::cout << "b.d = " << b.d    << std::endl;
}

Output of this example is then of course:

x   = 0
y   = 0
a.i = 0
b.d = 0

Answer 4

I would not assume that any implicit type will be initialized to 0. You may find this is the case when you are running inside the debugger and using the debug heap/stack. When you are outside of the debugger or disable the debug heap via _NO_DEBUG_HEAP=1 environment variable or otherwise you will find that memory is not initialized in most cases.

As a rule of thumb initialize your variables as it is safer to program this way.

EDIT: As pointed out by Luchian Grigore global/namespace scope variables are an exception. They also often don't work with uninitialized variable checks due to this initialization.