#include <iostream> int main() { struct pod { int i; }; struct inherit : pod { inherit() : pod() {} }; struct compose { compose() : p() {} pod p; }; inherit i; compose c; std::cout << i.i << std::endl; std::cout << c.p.i << std::endl; } In both cases the pod object is explicitly value-initialized, which according to 8.5para5 means that "every non-static data member ... is value-initialized" compose::pod::i is value-initialised, inherit::i is not. This can be seen from the values printed out for i.i and by using Purify. Same result with GCC 4.1.1, 3.4.3, 3.3.4 on Solaris 9, GCC 3.4.3 on AIX 5/3 Valgrind is being weird so I can't test it on Linux, butI don't think it's platform-dependent.
Values printed out confirm it on Linux for 3.3.5 20050117 (prerelease) (SUSE Linux), and official FSF 3.4.3, 4.0.1, 4.0.2, 4.1.1 N.B. I meant AIX 5.3, not 5/3
As compose is not POD it initializes p in the constructor. For inherit the constructor of p is called which - surprise - as a POD constructor does nothing.
(In reply to comment #2) > As compose is not POD it initializes p in the constructor. For inherit the > constructor of p is called which - surprise - as a POD constructor does > nothing. Actually read the standard, it does, see 8.5/7 and 8.5/5 the second part about default initializer.
Richard, there's no difference between pod() and p() in this case, both are value-initialisations of a POD class, therefore all non-static data members should be value-initialised. I cited 8.5p5 for good reason :) Sun CC 6.1 and 8 and IBM xlC 6 get this right.
Thsi is indeed a bug in g++. the pod() in inherit() is a value-initialization, not a call to default-constructor.
*** Bug 32141 has been marked as a duplicate of this bug. ***
Confirmed on x86-linux, sparc-solaris and ppc-AIX so I've removed the Target. Also verified that valgrind shows the uninitialised memory reads. This bug breaks common idioms like: template <typename A, typename B> struct compressed_pair : A { compressed_pair() : A(), second_() { } A& first() { return *this; } B& second() { return second_; } private: B second_; };
Jason is this the same issue as PR33916 you fixed? (Your fix didn't change the outcome of this PR though)
Subject: Bug 30111 Author: jason Date: Wed Feb 11 22:38:37 2009 New Revision: 144112 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144112 Log: PR c++/30111 * init.c (build_value_init_noctor): Split out from... (build_value_init): ...here. (expand_aggr_init_1): Handle value-initialization. * cp-tree.h: Add declaration. * class.c (type_has_user_provided_constructor): Handle non-class arguments. Added: trunk/gcc/testsuite/g++.dg/init/value7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog
Fixed for 4.4.
*** Bug 260998 has been marked as a duplicate of this bug. *** Seen from the domain http://volichat.com Marked for reference. Resolved as fixed @bugzilla.