Movatterモバイル変換

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

Tovalue-initialize an object of typeT means:

• ifT is a class type (9 class)with a user-declared constructor (12.1 class.ctor),then the default constructor forT is called(and the initialization isill-formed ifT has no accessible default constructor);
• ifT is a non-union class type without auser-declared constructor, thenevery non-static data member and base-class component ofT is value-initialized;
• ifT 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" in5.2.3 expr.type.conv paragraph2 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 andS2().y are also defined to beequal to zero, and here it really matters for many implementations, becauseifS2().y is just a bunch of random bits, it is entirely possiblethat trying to copyS2().y will yield a floating-point trap.

However, rather to my surprise, the standard does not define the valueofS3().x orS3().y, becauseS3 is not a POD.It does defineS3().s (by running the string constructor), butonce a structure is no longer a POD, the values of uninitialized membersare no longer guaranteed in expressions of the form T().

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

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

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