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.

Given:

    struct S1 {
        int x;
    };

    struct S2 {
        int x;
        double y;
    };

    struct S3 {
        int x;
        double y;
        string s;
    };

    void f()
    {
        S1 s1;

        // ...
    }

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.]