VS2013 list initialization

Question

Consider the code

#include "stdafx.h"
#include <Windows.h>
#include <iostream>

struct B
{
public:
    void f() { for (auto &v : member) { std::cout << v << std::endl; } }
private:
    int member[100];
};

int main()
{
    B b{};
    b.f();
}

I think this code is guided by $8.5.4/3

List-initialization of an object or reference of type T is defined as follows:
— If the initializer list has no elements and T is a class type with a default constructor, the object is value-initialized.

Instead the VS2013 compiler emits all 0xCCCCCCCC implying that it is leaving all elements of b.member as uninitialized. So, it appears it is performing default initialization instead of value initialization.

Please let me know if I am missing something.

Isn't that when you have a DEBUG compile? – Preet Sangha Jun 10 '14 at 03:30 — Preet Sangha, Jun 10 '14 at 03:30

selbie · Answer 1 · 2014-06-10T04:03:14.253

1

What you want to say is this:

int main()
{
    B b = {};  // = {} expresses that you want to zero-init the member vars
    b.f();
}

If B has a (non-default) constructor or any members with constructors, the above code sample of using ={} may generate a compiler error.

edited Jun 10 '14 at 04:03

answered Jun 10 '14 at 03:54

selbie

100,020
15
103
173

score 0 · Accepted Answer · answered Jun 10 '14 at 03:30

0

Your code sample can be simplified even further.

#include <iostream>

struct B
{
public:
    void f() { std::cout << member << std::endl; }
private:
    int member;
};

int main()
{
    B b{};
    b.f();
}

This produces the output:

-858993460

which is 0xCCCCCCCC in hex, the debug pattern the VC compiler fills memory with in Debug builds. This seems to be a known bug with both VS2012 and VS2013 as reported here.

You can work around the error by defining a constructor that value initializes the data member individually. In your case adding this constructor will result in all elements of member being 0

B() : member{} {}

answered Jun 10 '14 at 03:30

Praetorian

106,671
19
240
328

This defect however is not reproducible if the 'member' is made public. So, it appears to be in case of non aggregate classes – user3701522 Jun 10 '14 at 10:58
@user3701522 Yes, I can reproduce that too. But note that the behavior described above is still a bug. Value initialization does not differ based on accessibility of the members. – Praetorian Jun 10 '14 at 16:09

VS2013 list initialization

2 Answers2