Title
Definition of default-initialization
Status
tc1
Section
9.4 [dcl.init]
Submitter
Andrew Koenig

Created on 1998-07-29.00:00:00 last changed 254 months ago

Messages

Date: 1999-04-15.00:00:00

Proposed Resolution (04/99): Add the following text to the end of section 8.5  dcl.init paragraph 5:

To value-initialize an object of type T means:
  • if T is a class type (9  class ) with a user-declared constructor (12.1  class.ctor ), 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 storage for the object is zero-initialized.

Change "default-initialization" to "value-initialization" in 5.2.3  expr.type.conv paragraph 2 and in 8.5.1  dcl.init.aggr paragraph 7.

Date: 2004-09-10.00:00:00

Given:

    struct S1 {
        int x;
    };

    struct S2 {
        int x;
        double y;
    };

    struct S3 {
        int x;
        double y;
        string s;
    };
Once upon a time, we went through a fairly protracted discussion to ensure that S1().x would be guaranteed to be 0. Note that if we declare
    void f()
    {
        S1 s1;

        // ...
    }
there is no guarantee of the value of s1.x, and that is intentional. But S1().x is different, because S1() is an rvalue, and unless all of its members are defined, the effect of copying it is undefined.

Similarly, S2().x and S2().y are also defined to be equal to zero, and here it really matters for many implementations, because if S2().y is just a bunch of random bits, it is entirely possible that trying to copy S2().y will yield a floating-point trap.

However, rather to my surprise, the standard does not define the value of S3().x or S3().y, because S3 is not a POD. It does define S3().s (by running the string constructor), but once a structure is no longer a POD, the values of uninitialized members are no longer guaranteed in expressions of the form T().

In my opinion, this definition is a mistake, and the committee's intention was to zero-initialize all members that do not have an explicitly defined constructor, whether or not the class is a POD.

See also paper J16/99-0014 = WG21 N1191.

[Note: this issue is resolved by the resolution of issue 178.]

History
Date User Action Args
2003-04-25 00:00:00adminsetstatus: dr -> tc1
1999-09-14 00:00:00adminsetmessages: + msg206
1999-09-14 00:00:00adminsetstatus: drafting -> dr
1998-07-29 00:00:00admincreate