Why does a user-provided default constructor lead to an uninitialized member?

Question

Please consider the following code:

#include <iostream>

struct A{ // with implicit default constructor
       int number;
};

struct B{
       int number;
       B(){}; // user-provided default constructor
};

int main()
{
    A aa = {};
    B bb = {};

    std::cout << "aa.number: " << aa.number << std::endl;
    std::cout << "bb.number: " << bb.number << std::endl;    
}

Running the code online results in the following output:

aa.number: 0
bb.number: 19715

Why is bb.number uninitialized? I thought that zero initialisation is guaranteed by using ={} ?

Default initialization of primitive datatypes is not a guarantee of C++ and never was. The design principle is - you don't pay for what you don't use. There's an ample use case for uninitialized memory (think `char[10000]` for reading files into), ergo - it's not zero inited unless you explicitly say so. `int` members in classes are no different in that regard. — Seva Alekseyev, Feb 20 '20 at 13:51
@SevaAlekseyev "_Default initialization of primitive datatypes is not a guarantee of C++ and never was._" It is guaranteed that variables with `static`, or `thread_local` storage duration will be zero-initialized. — Algirdas Preidžius, Feb 20 '20 at 13:57
@SevaAlekseyev You could have done a simple search, about that: https://stackoverflow.com/questions/3373108/why-are-static-variables-auto-initialized-to-zero — Algirdas Preidžius, Feb 20 '20 at 14:03
@SevaAlekseyev [cppreference.com: zero initialization](https://en.cppreference.com/w/cpp/language/zero_initialization) — t.niese, Feb 20 '20 at 14:06
@SevaAlekseyev https://timsong-cpp.github.io/cppwp/basic.start.static#2 — NathanOliver, Feb 20 '20 at 14:09
@SevaAlekseyev Sorry about that. C++17 standard draft, section 6.8.3.2.2 ([basic.start.static]): "_If constant initialization is not performed, a variable with static storage duration or thread storage duration is zero-initialized._" — Algirdas Preidžius, Feb 20 '20 at 14:09

NathanOliver · Accepted Answer · 2020-02-20T13:46:55.367

10

I thought that zero initialisation is guaranteed by using ={} ?

That is only true if the type is "correct", which B is not. B bb = {}; will default construct a B and your default constructor, B(){};, doesn't initialize number so no matter what, number will never be initialized because that is how your default constructor works. If you had a "correct" constructor like

B() : number(0) {};
// or use
int number = 0;
B(){};

Then you'd get zero initialization of number when it is default constructed.

This isn't the case with A because A is an aggregate and those come with certain guarantees like zero initialization if an empty braced-init-list, technical name for the {}, is used.

edited Feb 20 '20 at 13:46

answered Feb 20 '20 at 13:42

NathanOliver

171,901
28
288
402

Can you explain what you mean by the type being "correct"? – 0x5453 Feb 20 '20 at 13:45
1

@0x5453 Added to the answer. – NathanOliver Feb 20 '20 at 13:47
I think your second option would be better if you `= default`ed the constructor with the member initialization. – sweenish Feb 20 '20 at 15:13

walnut · Answer 2 · 2020-02-20T14:26:45.207

A is an aggregate type, because it doesn't have any user-provided constructors (and fulfills a few other requirements).

Therefore A aa = {}; does not call the implicitly generated default constructor. Instead initialization with brace-enclosed initializer lists performs aggregate initialization, which for an empty list means that the members are initialized as if by a {} initializer, which in turn means for a member of scalar type such as int that it will be initialized to zero.

B is not an aggregate type, because it does have a user-provided constructor.

Therefore B bb = {}; cannot do aggregate initialization and will call the default constructor instead. The default constructor (in either A or B) does not specify an initializer for the members and so the member is default-initialized, which for a fundamental type, such as int, means that it will not be set to any value. Its value will remain indeterminate.

Accessing the indeterminate value, which your program does, causes undefined behavior.

If you declare a constructor yourself, then it becomes that constructor's responsibility to initialize all the members appropriately. The rule that = {} or {} always initializes only holds under the assumption that a user-provided default constructor, if it exists, does the right thing in the sense that it provides sensible initializers to all its members and it doesn't have to mean zero-initialization necessarily.

score 2 · Answer 3 · answered Feb 20 '20 at 13:47

2

struct B has a user-provided constructor, so it doesn't get the default constructor that can initialize the members to zero. Your user-provided constructor replaces that, so you have to do the work yourself.

answered Feb 20 '20 at 13:47

Matt Timmermans

53,709
3
46
87

Why does a user-provided default constructor lead to an uninitialized member?

3 Answers3