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'. 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. (I do see now that X() counts as value-initialization, which I had missed earlier.) > [dcl.fct.def.default]/4: A member function is user-provided if it is > user-declared and not explicitly defaulted or deleted on its first > declaration. > > Thus X() performs zero-initialization before calling the default constructor. > Even when used in a delegating initialization. Jordy _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
