Boost logo

Boost :

Subject: Re: [boost] [variant] Please vote for behavior (Was: Basic rvalue and C++11 features seupport)
From: Larry Evans (cppljevans_at_[hidden])
Date: 2013-01-28 11:47:44


On 01/21/13 18:25, Joel de Guzman wrote:
> On 1/22/13 8:13 AM, Jeffrey Lee Hellrung, Jr. wrote:
>> On Mon, Jan 21, 2013 at 3:54 PM, Joel de Guzman <djowel_at_[hidden]> wrote:
>>
>>> On 1/22/13 7:49 AM, Jeffrey Lee Hellrung, Jr. wrote:
>>>
>>>> On Mon, Jan 21, 2013 at 3:33 PM, Joel de Guzman <djowel_at_[hidden]>
>>>> wrote:
>>>>
>>>> On 1/22/13 3:57 AM, Antony Polukhin wrote:
>>>>>
>>>>> I've got some nice idea from discussion: nullable variant. If many
>>>>>> people use or want to use a variant with a type, that represents
>>>>>> empty
>>>>>> state, we can create a separate nullable variant class. I think that
>>>>>> nullable variant can be implemented more efficient that the current
>>>>>> variant. For example we can simplify copy/move constructors and
>>>>>> assignment operators, guarantee fast noexcept default construction,
>>>>>> simplify metaprogamming and reduce compilation times. Maybe someone
>>>>>> want to implement it?
>>>>>>
>>>>>>
>>>>> I like it! If you implement it, I'll be your first user :-)
>>>>> I don't really care much about this "never empty" guarantee and
>>>>> I think it's not really worth the trouble.
>>>>>
>>>>>
>>>> How is this different from variant< blank, ... > ?
>>>>
>>>
>>> Less work behind the scenes.
>>
>>
>> You mean fewer LOC / simpler implementation (believable) or faster
>> compiled
>> code (I'd be skeptical)?
>
> Agreed.
>
>>> Lighter TMP load.
>>
>>
>> Agreed, but I'm not sure how much the "never empty guarantee" accounts
>> for
>> the present TMP load.
>
> Agreed.
>
>> better noexcept
>>> guarantees. Etc.
>>>
>>
>> I don't see this. I would think constructing blank has the same noexcept
>> guarantees as assigning a pointer to null, and can equally well be
>> propagated out to the variant interface. You might have a specific
>> case in
>> mind, though?
>
> No. After thinking about it for a while, you are right.
>
>> Do you presently use variant< blank, ... >? If not, is it because of the
>> above reasons?
>
> I *always* use variant< blank, ... > (or something similar). And that is
> precisely why I don't care much about the never-empty guarantee.
>
> Regards,

I'm a bit confused about what nullable variant means. I can see 2
possible interpretations:

  1) allow recursive_wrapper<T>::_p == 0.
     This only occurs when moving from a variant
     containing a recursive_wrapper.
  2) ensure a moved from variant is put into the same
     state as a default constructed variant.

Am I missing something?

-regards,
Larry


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk