Date: Sat, 1 Feb 2020 14:46:14 +0100
>
> Or, even better, remove definition of `optional()` to make it
> trivially-default-constructible?
Removing the definition of optional() (or in general having it not
user-provided) makes it deleted for T that have non-trivial default
constructor (since T is in union).
but I still don't see a reason to value-initialize `dummy`.
Value-initialization appears to be needed for the constructor to be
constexpr. I couldn't find where this is required (or maybe was lifted) in
the current draft, but in pre-C++17 N4140 [dcl.constexpr] says:
> The definition of a constexpr constructor shall satisfy the following
> constraints:
> - ...
> - if the class is a union-like class, but is not a union, for each of its
> anonymous union members having variant members, exactly one of them shall
> be initialized;
I'm not sure, but I assume that "initialized" here means explicit
initialization in member-init-list, in which case only value- (or list-)
initialization is possible for optional. I assume that this might recently
have been lifted though.
сб, 1 февр. 2020 г. в 08:13, Andrey Davydov <andrey.davydov_at_[hidden]>:
> On Sat, Feb 1, 2020 at 10:04 AM Andrey Davydov <
> andrey.davydov_at_[hidden]> wrote:
>
>> On Fri, Jan 31, 2020 at 6:07 PM Anton Bikineev via Std-Discussion <
>> std-discussion_at_[hidden]> wrote:
>>
>>> The Standard says:
>>>
>>> To *value-initialize*
>>>> <http://eel.is/c++draft/dcl.init#def:value-initialization> an object
>>>> of type T means:
>>>>
>>>> - - if T is a (possibly cv-qualified) class type with either no
>>>> default constructor or a default constructor that is user-provided or
>>>> deleted, then the object is default-initialized;
>>>>
>>>>
>>>> - - if T is a (possibly cv-qualified) class type without a
>>>> user-provided or deleted default constructor, **then the object is
>>>> zero-initialized** and the semantic constraints for
>>>> default-initialization are checked, and if T has a non-trivial
>>>> default constructor, the object is default-initialized;
>>>>
>>>>
>>>> - - ...
>>>>
>>>>
>>> I'm wondering, why in C++11 an object needs to be zero-initialized (this
>>> was not the case before C++11)? I can't find a proposal/DR that changes
>>> that, but I suspect that this is to align with value-initialization of
>>> scalar types (which implies zero-initializaiton).
>>>
>>
>> I'm sure symmetry with value-initialization of scalar types is the
>> reason. It would be very strange if for the `pair<int, array<int, 1>> p;`
>> p.first == 0, but p.second[0] has indeterminate value.
>>
>>
>>> The problem is that this leads to suboptimal code generation:
>>> https://godbolt.org/z/pwYjLP (this is a minimized example from optional
>>> implementation in abseil).
>>>
>>
>> Is it possible just to remove mem-initializer for `dummy` (
>> https://godbolt.org/z/22zBTu)? Or, even better, remove definition of
>> `optional()` to make it trivially-default-constructible?
>>
>
> Sorry, `optional()` couldn't be trivially-default-constructible (due to
> initialization of `is_populated`), but I still don't see a reason to
> value-initialize `dummy`.
>
> --
> Andrey Davydov
>
> Or, even better, remove definition of `optional()` to make it
> trivially-default-constructible?
Removing the definition of optional() (or in general having it not
user-provided) makes it deleted for T that have non-trivial default
constructor (since T is in union).
but I still don't see a reason to value-initialize `dummy`.
Value-initialization appears to be needed for the constructor to be
constexpr. I couldn't find where this is required (or maybe was lifted) in
the current draft, but in pre-C++17 N4140 [dcl.constexpr] says:
> The definition of a constexpr constructor shall satisfy the following
> constraints:
> - ...
> - if the class is a union-like class, but is not a union, for each of its
> anonymous union members having variant members, exactly one of them shall
> be initialized;
I'm not sure, but I assume that "initialized" here means explicit
initialization in member-init-list, in which case only value- (or list-)
initialization is possible for optional. I assume that this might recently
have been lifted though.
сб, 1 февр. 2020 г. в 08:13, Andrey Davydov <andrey.davydov_at_[hidden]>:
> On Sat, Feb 1, 2020 at 10:04 AM Andrey Davydov <
> andrey.davydov_at_[hidden]> wrote:
>
>> On Fri, Jan 31, 2020 at 6:07 PM Anton Bikineev via Std-Discussion <
>> std-discussion_at_[hidden]> wrote:
>>
>>> The Standard says:
>>>
>>> To *value-initialize*
>>>> <http://eel.is/c++draft/dcl.init#def:value-initialization> an object
>>>> of type T means:
>>>>
>>>> - - if T is a (possibly cv-qualified) class type with either no
>>>> default constructor or a default constructor that is user-provided or
>>>> deleted, then the object is default-initialized;
>>>>
>>>>
>>>> - - if T is a (possibly cv-qualified) class type without a
>>>> user-provided or deleted default constructor, **then the object is
>>>> zero-initialized** and the semantic constraints for
>>>> default-initialization are checked, and if T has a non-trivial
>>>> default constructor, the object is default-initialized;
>>>>
>>>>
>>>> - - ...
>>>>
>>>>
>>> I'm wondering, why in C++11 an object needs to be zero-initialized (this
>>> was not the case before C++11)? I can't find a proposal/DR that changes
>>> that, but I suspect that this is to align with value-initialization of
>>> scalar types (which implies zero-initializaiton).
>>>
>>
>> I'm sure symmetry with value-initialization of scalar types is the
>> reason. It would be very strange if for the `pair<int, array<int, 1>> p;`
>> p.first == 0, but p.second[0] has indeterminate value.
>>
>>
>>> The problem is that this leads to suboptimal code generation:
>>> https://godbolt.org/z/pwYjLP (this is a minimized example from optional
>>> implementation in abseil).
>>>
>>
>> Is it possible just to remove mem-initializer for `dummy` (
>> https://godbolt.org/z/22zBTu)? Or, even better, remove definition of
>> `optional()` to make it trivially-default-constructible?
>>
>
> Sorry, `optional()` couldn't be trivially-default-constructible (due to
> initialization of `is_populated`), but I still don't see a reason to
> value-initialize `dummy`.
>
> --
> Andrey Davydov
>
-- Sincerely, Anton.
Received on 2020-02-01 07:49:01