[cfe-commits] r157138 - in /cfe/trunk: lib/CodeGen/CGExprCXX.cpp test/CodeGenCXX/cxx0x-delegating-ctors.cpp
jediknil at belkadan.com
Sun May 20 07:50:01 PDT 2012
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 <jediknil at belkadan.com> 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-qualiﬁed) 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.
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!
More information about the cfe-commits