struct A
{
int a;
std::string str;
};
A a;// 1
A a{};// 2
A a = {};// 3
A a = A();// 4
There seems to be all options. In case 1 and 4 a will be uninitialized, in 2 and 3 a will be initialized with zero and they both are same and just the matter of style or there is some difference? 4 supposed to first create a temporary object and then assign it to an a, but it will happen only if I will turn off comliler's optimization completely, right?
For all the cases the data member str is always default-initialized by the default constructor of std::string. Due to the different initialization styles, the data member a might be initialized to 0 or indeterminate value. In details,
The 1st one is default initialization, as the result a.a is initialized to indeterminate value (or gets zero-initialized to 0 if a is static or thread-local object), a.str is initialized by its default constructor.
The 2nd one is direct-list-initialization and aggregate initialization is performed, as the result a.a is value-initialized (zero-initialized) to 0, a.str is initialized by its default constructor.
The 3rd one is copy-list-initialization and aggregate initialization is performed, as the result a.a is value-initialized (zero-initialized) to 0, a.str is initialized by its default constructor.
In concept the 4th one is copy initialization, a is copy-initialized from A() (value-initialized temporary A). Because of copy elision (since C++17 it's mandatory) a might be value-initialized directly, as the result (which doesn't get changed by copy elision) a.a is zero-initialized to 0, a.str is initialized by its default constructor.
Related
I found many articles explaining the difference between "default-initialization and value-initialization" but in fact I didn't understand clearly.
Here's an example:
class A{
public:
int x;
};
int main(){
A a;// default initialization so x has undefined value.
A b = A(); // value initialization so x is a scalar thus it is value initialized to 0
}
Above it is OK as I guess but here:
int value = 4; // is this considered a value-initialization?
Please help me understand the major differences between the two forms of initializations.
A a; is default initialization, as the effect the default constructor of A is used for initialization. Since the implicitly-generated default constructor of A does nothing, a.x has indeterminate value.
A() is value initialization,
if T is a class type with a default constructor that is neither user-provided nor deleted (that is, it may be a class with an implicitly-defined or defaulted default constructor), the object is zero-initialized and then it is default-initialized if it has a non-trivial default constructor;
Note the difference with default initialization, A has an implicitly-defined default constructor, and the object is zero-initialized; so the data memeber x of the temporary object A() will be initialized to 0.
A b = A(); is copy initialization, in concept b is initialized from the temporary object A(), so b.x will be initialized to 0 too. Note that because of copy elision, since C++17 b is guaranteed to be value-initialized directly; the copy/move construction is omitted.
int value = 4; is copy initialization too. value will be initialized to 4.
What is the difference between:
auto x = vector<int>();
and
vector<int> x;
Are both of these declarations equivalent, or is there some difference with the run-time complexity?
They have the same effect since C++17. Both construct an object named x with type std::vector<int>, which is initialized by the default constructor of std::vector.
Precisely the 1st one is copy initialization, x is copy-initialized from a value-initialized temporary. From C++17 this kind of copy elision is guaranteed, as the result x is initialized by the default constructor of std::vector directly. Before C++17, copy elision is an optimization:
even when it takes place and the copy/move (since C++11) constructor is not called, it still must be present and accessible (as if no optimization happened at all), otherwise the program is ill-formed:
The 2nd one is default initialization, as a class type x is initialized by the default constructor of std::vector.
Note that the behaviors might be different for other types, depending on the type's behavior and x's storage duration.
I have a simple struct with an array:
struct A
{
uint32_t arr[size];
};
I have two functions, which create it using default initialization and value initialization:
template<class T>
void testDefault()
{
T* pa = new T; // Default
use(*pa);
delete pa;
}
template<class T>
void testValue()
{
T* pa = new T(); // Value
use(*pa);
delete pa;
}
I'm facing different performance for those functions. The funny thing is that performance differences vary depending on how I declare default constructor of the struct. I have three ways:
struct A
{
uint32_t arr[size];
// Implicit constructor
};
struct B
{
uint32_t arr[size];
B() {}; // Empty constructor
};
struct C
{
uint32_t arr[size];
C() = default; // Defaulted constructor
};
I thought they are all the same from compiler's point of view. Never have been I so wrong. I did run both testDefault() and testValue() several times with structs A, B and C and measured performance. Here is what I have:
Default initialization (implict constructor) done in 880ms
Value initialization (implict constructor) done in 1145ms
Default initialization (empty constructor) done in 867ms
Value initialization (empty constructor) done in 865ms
Default initialization (defaulted constructor) done in 872ms
Value initialization (defaulted constructor) done in 1148ms
Note how performance is clearly worse for both implicit and defaulted constructors. Only empty constructor correctly shows the same performance for both different initialization forms.
I tested this with VC++, gcc and clang. See online demo for gcc. Timings are quite persistent.
What I assume is:
Default and value initializations for UDT are the same thing
All demonstrated ways of defining default constructor are doing the same thing
Default constructor of these structs should leave content of the array in indeterminate state
Since all the compilers exhibit the same timings, it seems like I'm missing something. Can anyone please explain me these timings?
(See also my question Why compilers put zeros into arrays while they do not have to? on the same topic. I give some links to cppreference there.)
Let's look at the definition of value-initialize:
To value-initialize an object of type T means:
if T is a (possibly cv-qualified) class type with either no default constructor (12.1) or a default constructor that is user-provided or deleted, then the object is default-initialized;
if T is a (possibly cv-qualified) class type without a user-provided or deleted default constructor, then the object is zero-initialized [...];
if T is an array type, then each element is value-initialized;
otherwise, the object is zero-initialized.
Also let's review the adjectives in use here for constructors:
user-declared - you declared the constructor
user-provided - you declared the constructor and didn't set it to = default or = delete
default - can be called with no arguments
declared as defaulted - marked = default; or implicitly generated as such
Looking at your classes:
A has a default constructor which is implicitly declared as defaulted, and not user-provided.
C has a default constructor which is user-declared as defaulted, and not user-provided.
So the second bullet point in the definition of value-initialize applies. The object is zero-initialized, meaning the arr is zeroed out.
B has a default constructor which is user-provided.
So the first bullet point of value-initialize applies to B; value-initialization is the same as default-initialization here, and arr is not zeroed out.
Your timings correctly seem to correspond to what is expected: value-initialization of A or C zeroes out arr and the other cases don't.
One of the constructors behaves differently under value initialization. In this version,
B() {};
the array B::arr is not value-initialized when the B is. With the others, it is. Whether this explains the performance difference is another matter.
So, B::arr doesn't get zero-initialized with value initialization, whereas A::arr and C::arr do. All three cases have the same behaviour under default initialization, that is to say, arr gets default-initialized, i.e. no initialization is performed.
I cannot understand the behavior of gcc 4.8.1 or Visual Studio 2015 with respect to default initialization versus value initialization.
It doesn't help that I'm trying to understand the differences between these myself and possibly running into compiler bugs?
My question is: Can someone explain this behavior? And ideally tell me what should be happening.
I have two classes:
class Foo{
int _bar;
public:
void printBar(){ cout << _bar << endl; }
};
class bar{
int ent;
public:
int getEnt(){return ent;}
};
I'm using the following code to test:
int main()
{
Foo foo;
foo.printBar();
Foo().printBar();
bar b;
cout << b.getEnt() << endl;
return 0;
}
On gcc and Visual Studio I get:
134514795
0
0
Now if I change the test code to:
int main()
{
Foo foo;
foo.printBar();
bar b;
cout << b.getEnt() << endl;
return 0;
}
gcc gives me:
0
0
And Visual Studio gives me:
50790236
51005888
Default initialisation, of classes like this without user-defined constructors, does nothing, leaving each trivial member with an indeterminate value.
Value initialisation will zero-initialise each member.
In the first case, you're printing:
the indeterminate value of a default-initialised Foo foo;
the zero value of a value-initialised Foo()
the indeterminate value of a default-initialised bar b;
The third one happens to be zero; perhaps because it reuses the storage of the temporary value-initialised Foo.
In the second case, you're printing the indeterminate values of two default-initialised objects. Coincidentally, they have zero values in one case but not the other.
Both programs have undefined behaviour, since they use uninitialised values.
The logic is quite simple:
Default initialization of a class just default initializes all members.
Default initialization of built-in types leaves member uninitialized.
Accessing an uninitialized object yields undefined behavior.
Undefined behavior can do anything it wants.
Both compilers provide "correct" results. Note that causing nasal demons to be emitted would also be correct.
Foo foo;
This default-initializes foo, and since Foo's default constructor is trivial, it effectively doesn't initialize it at all, so foo._bar can hold any value (including 0).
Foo()
This value-initializes the temporary object, which in case of trivial default constructor means zero-initialization, so Foo()._bar is equal to 0.
n3376 quotes
8.5/11
If no initializer is specified for an object, the object is
default-initialized; if no initialization is performed, an object with
automatic or dynamic storage duration has indeterminate value. [ Note:
Objects with static or thread storage duration are zero-initialized,
see 3.6.2. — end note ]
8.5/6
To default-initialize an object of type T means: if T is a (possibly
cv-qualified) class type (Clause 9), the default constructor for T is
called (and the initialization is ill-formed if T has no accessible
default constructor);
8.5/10
An object whose initializer is an empty set of parentheses, i.e., (),
shall be value-initialized.
8.5/7
To value-initialize an object of type T means:
...
otherwise, the object is zero-initialized.
8.5/5
To zero-initialize an object or reference of type T means: if T is a
(possibly cv-qualified) non-union class type, each non-static data
member and each base-class subobject is zero-initialized and padding
is initialized to zero bits;
So, in your case, there are nor static storage duration variables, nor thread-local variables, so objects foo and b will be default-initialized, that means, that constructor will be called. Default-constructor (not user-defined) will not initialize members and in members will be arbitrary garbage and this arbitrary garbage may be 0 (thanks to Jarod42 for point this in comment).
And Foo().printBar(); should print 0, since object is zero-initialized.
I am learning C++ and I am a bit confused about the initialization of int variables.
This code (including the comments) is a copy/paste from Nawaz's answer in this topic Why does C++ require a user-provided default constructor to default-construct a const object?
struct POD
{
int i;
};
POD p1; //uninitialized - but don't worry we can assign some value later on!
p1.i = 10; //assign some value later on!
POD p2 = POD(); //initialized
For p2, I understand that the following is happening:
The default constructor POD() is called to create a temporary POD object. The constructor is not user-defined, so it is implicit. For built-in types like int, the implicit default constructor does nothing (no initialization). Therefore i contains some random stuff.
The copy constructor is called to create p2 using the temporary POD object (whose i is still uninitialized). Therefore the i member of p2 should not be initialized either.
However, the comment says that p2 is initialized!
Any explanation is welcome. Thanks.
For built-in types like int, the implicit default constructor does nothing (no initialization).
This is true but it is also not. Default initialization results in an unitialized object, while value initialization doesn't.
Why are these cases different?
1. C++11, 8.5/11
If no initializer is specified for an object, the object is default-initialized; if no initialization is performed, an object with automatic or dynamic storage duration has indeterminate value.
If you use int i; this results in an uninitialized integer!
2. C++11, 8.5/10
An object whose initializer is an empty set of parentheses, i.e., (), shall be value-initialized.
If you use int i = int(); you have a value-initialized i. Now, what is value-initialized?
3. C++11, 8.5/7
To value-initialize an object of type T means:
[...] (some options where T may be class or array type)
otherwise, the object is zero-initialized.
Ok now we know that int i = int(); means having i=0.
Since your struct is POD, value-initializing it means value-initializing all of its members.
You can have a shortcut on the general behaviour
int i1, i2 = int();
std::cout << i1 << std::endl;
std::cout << i2 << std::endl;
If the memory where i1 resides, isn't zero by any luck you can have the output will probably be
somevalue
0
[As #jogojapan mentioned correctly: Reading from i1 is undefined in first place, so don't do it. You'll most likely observe what I describe here but since the standard doesn't enforce compilers to behave this way i1 may be zero, or brake the expected result in any other strange way.]
Be aware of the following:
Note: Since () is not permitted by the syntax for initializer,
X a();
is not the declaration of a value-initialized object of class X, but the declaration of a function taking no argument and returning an X.
Emphasis on standard quotes are mine.
If class type POD has no user-defined constructor (as is the case in your example), then POD() does not call default constructor. Instead the object is created without using any constructors at all. The compiler performs so called value-initialization of the temporary object. Value-initialization is a self-sufficient method of initialization, which does not necessarily use constructors. Instead, value-initialization of the entire object recursively performs value-initialization of all of its subobjects, one after another. For members of type int value-initialization means zero-initialization.
This is why POD().i is guaranteed to be zero. That zero was not placed there by any constructors. That zero was placed there by value-initialization.