On May 20, 2012, at 2:38, John McCall wrote: > On May 19, 2012, at 9:34 PM, Jordan Rose wrote: >> On May 20, 2012, at 0:20, Richard Smith wrote: >>> On Sat, May 19, 2012 at 6:43 PM, Jordy Rose <[email protected]> wrote: >>>> I am not a standardista, but this doesn't seem right to me. The target >>>> constructor finishes before the delegating constructor runs, and >>>> presumably the target constructor has to be able to initialize the entire >>>> object by itself. I don't see anything in the standard that says 'x' is >>>> zero-initialized by the default constructor on its own, the default >>>> constructor as a target, or the delegating constructor. >>>> >>> [class.base.init]/7: The expression-list or braced-init-list in a >>> mem-initializer is used to initialize the designated subobject (or, in the >>> case of a delegating constructor, the complete class object) according to >>> the initialization rules of [dcl.init] for direct-initialization. >>> [dcl.init]/10: An object whose initializer is an empty set of parentheses, >>> i.e., (), shall be value-initialized. >>> [dcl.init]/7: To value-initialize an object of type T means: [...] if T is >>> a (possibly cv-qualified) non-union class type without a user-provided >>> constructor, then the object is zero-initialized [...] >> >> But X /does/ have a user-provided constructor -- X::X(int). Or it will after >> we finish defining it. Thus we should just call the implicit default >> constructor, which will not initialize 'x'. > > Richard has quoted an old draft (to be fair, I think it's probably the > official standard). The most recent language (N3376) is more clear: > > • To value-initialize an object of type T means: > > • — if T is a (possibly cv-qualified) class type (Clause 9) > with either no default constructor (12.1) or a default constructor that is > user-provided or deleted, then the object is default-initialized; > > • — if T is a (possibly cv-qualified) non-union class type > without a user-provided or deleted default constructor, then the object is > zero-initialized and, if T has a non-trivial default constructor, > default-initialized; > > • — if T is an array type, then each element is > value-initialized; > > • — otherwise, the object is zero-initialized. > >> That's a technicality, but one that feels like C++ to me. Otherwise you have >> to pay for the zero-initialization whether you use it or not. > > It's a delegating constructor call to an explicitly-defaulted default > constructor. If you don't want to pay for the zero-initialization, just omit > the delegating initialization, and your constructor will do all the > default-constructing that the defaulted default constructor would have. > > Of course, the semantic difference between value-initialization and > default-initialization is really subtle, but that's just C++ for you. > > John.
Okay, thank you for explaining that; actually, thank you both. The addition of "default" does make a difference there. And that means Eli's commit is correct! Jordy _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
