Boost logo

Boost :

Subject: Re: [boost] [variant] Please vote for behavior (Was: Basic rvalue and C++11 features seupport)
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2013-01-21 19:13:26


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)?

> Lighter TMP load.

Agreed, but I'm not sure how much the "never empty guarantee" accounts for
the present TMP load.

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?

Do you presently use variant< blank, ... >? If not, is it because of the
above reasons?

- Jeff


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