This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 115e. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2024-11-11
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.]