21

Given the following code:

class temp
{
public:
    string str;
    int num;
};

int main()
{
    temp temp1;
    temp temp2 = temp();

    cout << temp1.str << endl; //Print ""
    cout << temp2.str << endl; //Print ""

    cout << temp1.num << endl; //Print a rand num
    cout << temp2.num << endl; //Print 0
}

What is the different between these two?—

temp temp1;

and

temp temp2 = temp();
Keith Pinson
  • 7,835
  • 7
  • 61
  • 104
onestar
  • 213
  • 2
  • 4

3 Answers3

23
temp temp1;

This calls temp's default constructor on the instance called temp1.

temp temp2 = temp();

This calls temp's default constructor on a temporary object, then calls the compiler-generated copy-constructor on temp2 with the temporary object as the argument (this of course assumes that the compiler doesn't elide copies; it depends on your compiler's optimization settings).

As for why you get different initialized values, section 8.5 of the standard is relevant:


8.5 Initializers [dcl.init]

Paragraph 5:

To zero-initialize an object of type T means:
  • if T is a scalar type (3.9), the object is set to the value of 0 (zero) converted to T;
  • if T is a non-union class type, each nonstatic data member and each base-class subobject is zero-initialized;
  • if T is a union type, the object’s first named data member is zero-initialized;
  • if T is an array type, each element is zero-initialized;
  • if T is a reference type, no initialization is performed.

To default-initialize an object of type T means:

  • if T is a non-POD class type (clause 9), the default constructor for T is called (and the initialization is ill-formed if T has no accessible default constructor);
  • if T is an array type, each element is default-initialized;
  • otherwise, the object is zero-initialized.

To value-initialize an object of type T means:

  • if T is a class type (clause 9) with a user-declared constructor (12.1), then the default constructor for T is called (and the initialization is ill-formed if T has no accessible default constructor);
  • if T is a non-union class type without a user-declared constructor, then every non-static data member and base-class component of T is value-initialized;
  • if T is an array type, then each element is value-initialized;
  • otherwise, the object is zero-initialized.

Paragraph 7:

An object whose initializer is an empty set of parentheses, i.e., (), shall be value-initialized.

Paragraph 9:

If no initializer is specified for an object, and the object is of (possibly cv-qualified) non-POD class type (or array thereof), the object shall be default-initialized; if the object is of const-qualified type, the underlying class type shall have a user-declared default constructor. Otherwise, if no initializer is specified for a nonstatic object, the object and its subobjects, if any, have an indeterminate initial value; if the object or any of its subobjects are of const-qualified type, the program is ill-formed.

12 Special Member Functions [special]

Paragraph 7:

An implicitly-declared default constructor for a class is implicitly defined when it is used to create an object of its class type (1.8). The implicitly-defined default constructor performs the set of initializations of the class that would be performed by a user-written default constructor for that class with an empty mem-initializer-list (12.6.2) and an empty function body.

12.6.2 Initializing bases and members [class.base.init]

Paragraph 4:

If a given nonstatic data member or base class is not named by a mem-initializer-id (including the case where there is no mem-initializer-list because the constructor has no ctor-initializer), then
  • If the entity is a nonstatic data member of (possibly cv-qualified) class type (or array thereof) or a base class, and the entity class is a non-POD class, the entity is default-initialized (8.5). If the entity is a nonstatic data member of a const-qualified type, the entity class shall have a user-declared default constructor.
  • Otherwise, the entity is not initialized. If the entity is of const-qualified type or reference type, or of a (possibly cv-qualified) POD class type (or array thereof) containing (directly or indirectly) a member of a const-qualified type, the program is ill-formed.

So now that the rules have been laid out, let's see how they apply:

temp temp1;

temp is a non-POD type (because it has a std::string member), and since no initializer is specified for temp1, it will be default-initialized (8.5/9). This calls the default constructor (8.5/5). temp has an implicit default constructor (12/7) which default-initializes the std::string member and the int member isn't initialized at all (12.6.2/4).

temp temp2 = temp();

On the other hand, the temporary temp object is value-initialized (8.5/7), which value-initializes all data members (8.5/5), which calls the default constructor in the std::string member and zero-initializes the int member (8.5/5).

Of course, if you much rather not have to refer to the standard in 5+ different places, just ensure that you explicitly initialize everything (e.g. int i = 0; or using initializer lists).

In silico
  • 51,091
  • 10
  • 150
  • 143
  • @In silico: w.r.t my answer, it would seem that MSVC is non conformant in this case? As there is no user-declared ctor, the `int temp::num`should be zero initialized and not spout random numbers on the second example `temp temp2 = temp();`, right? Or am I wrong somehow? – Xeo May 14 '11 at 03:25
  • @Xeo: Some compilers are not completely standards conforming with respect to §8.5, I believe I saw a Microsoft Connect entry that has to do with this. Value-initialization is new to C++03; I think MSVC++ uses C++98 rules w.r.t. §8.5. – In silico May 14 '11 at 03:29
  • 1
    @Xeo: The quotes above are taken from C++03 standard, while MSVC compilers still mostly stick to C++98. – AnT stands with Russia May 14 '11 at 03:34
  • @In silico: Strictly speaking, the second initialization does not produce a temporary `temp` object. The syntax is that of a *copy-initialization*, but since the class types on the LHS and RHS are the same, this initialization is processed as *direct-initialization* (per 8.5/14). No temporary is created. Note, this is not a result of *copy elision* that eliminated the temporary. The temporary never existed in the first place. – AnT stands with Russia May 14 '11 at 15:29
  • @AndreyT: I can see why it involves direct-initialization (because the left and right operand is of the same type and thus is equivalent to `temp temp2((temp()))`), but I don't understand why there isn't a temporary in the first place. It seems to me that by 12.8/15 there is in fact a temporary that's being elided here. – In silico May 15 '11 at 00:24
  • @In silico: I actually removed my comments because I have a strong feeling that I'm wrong here. You are actually right - what 8.5/14 is trying to say is that it is equivalent to `temp temp2(temp())`. And then the regular copy elision applies. I'm sorry for starting this confusion. – AnT stands with Russia May 15 '11 at 02:30
  • @AndreyT: That was the one thing that I was confused about (I've rolled back my last edit). I didn't see anywhere that said that it was a special case in a way that didn't involve temporaries, except that the compiler is allowed to elide temporaries. And an apology isn't necessary; I needed to do a closer reading of the standard anyway. :-) – In silico May 15 '11 at 02:35
5

The behavior of your code depends critically on the compiler you are using. More precisely, it depends on which version of language specification your compiler implements.

For C++98 compilers, both declarations have identical effect on the final values of the objects being declared: the str member should become empty, while the num members should contain unpredictable value. In both cases the actual initialization is default-initialization performed by a compiler-provided default constructor of class temp. That default constructor initializes str, but leaves num uninitialized.

For C++03 compilers the behavior is different. There's no difference for temp1 object (its num is still unpredictable). But temp2 initialization is handled differently. In C++03 the () initializer triggers the new kind of initialization - so called value-initialization. Value-initialization ignores the compiler-provided default constructor of the top level object, and instead works directly on its subobjects (data members in this case). So the temp2 object is effectively initialized by value-initialization, which also sets the num member to zero (in addition to initializing str with an empty string). For this reason, temp2.num ends up being zero in C++03 compilers.

If in your experiments you observed consistent zero in temp2.num, it means that your compiler follows the C++03 specification in this respect.

AnT stands with Russia
  • 312,472
  • 42
  • 525
  • 765
4
temp temp1;

Will create a default initialized temp object. Since you provided no default constructor for temp, every member of temp will be default initialized too. Since std::string provides a default ctor, it gets initialized correctly and has a well-defined value. The integer, however, gets default initialized, which is implementation defined and normally a random value.

temp temp2 = temp();

This will first create a value initialized temp object. This is important, because the object itself is value initialized, so are its members. It doesn't matter for the string, as default and value initialization are the same, but it matters for the integer. A value initialized integer has the value 0.
After that, you just copy over those members into temp2.

Also, this relevant question might be of interest to you.
Edit: See my comment on @In silico's answer for explanation on why this isn't the case for MSVC. :/

Community
  • 1
  • 1
Xeo
  • 129,499
  • 52
  • 291
  • 397
  • 1
    Note that if there had been a user-defined default constructor for `temp`, that the value initialization would not zero-out the integer data member. – Jason May 14 '11 at 03:13
  • This must be compiler dependent, I tried it on MSVC++ 2010 and it prints random numbers for both objects. – Seth Carnegie May 14 '11 at 03:17
  • 1
    @Jason: It would if provided correctly :) `temp() : str(), num()`. – Xeo May 14 '11 at 03:17
  • @Seth: Interesting, I'm using VS2010 too and I could swear I'd normally get a zero initialized integer, but it seems my memory serves me wrong... – Xeo May 14 '11 at 03:20
  • 1
    @Seth: See my comment on @In silico's answer, seems MSVC is just non-conforming to the standard in this case. – Xeo May 14 '11 at 03:30
  • @Xeo: Yes, true, but in your version of the constructor, you are now explicitly value-initializing the `str` and `num` members. That is not the same as the value-initialization of the `temp` class itself, which simply calls the user-defined constructor if it exists, or zero-initializes the `temp` object if it does not have a user-defined constructor. So basically value-initialization, if there is a user-defined constructor, does not guarantee that the object is zero-initialized unless all non-static data members are explicilty value-initialized as well in the constructor. – Jason May 14 '11 at 03:33
  • BTW, it seems from the post that Xeo referenced that MSVC does not support value-initialization (at least not in 2008), but only zero and default initialization from C++98. So this still may be true in 2010? – Jason May 14 '11 at 03:36
  • @Jason: You never said it wasn't allowed to initialize every member explicitly. :P You only said if a ctor was provided by the user, it would still not zero-out the integer member. – Xeo May 14 '11 at 03:37
  • @Jason: See @AndreyT's comment on @In silico's answer. – Xeo May 14 '11 at 03:37