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-24 14:56:03

On 01/21/13 17:51, Hartmut Kaiser 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.
> I'd prefer to have a nullable variant as well. If not that, then I would
> like to support II: Set operand.p_ to NULL, add BOOST_ASSERT in get
> operations.

OR have get<T> return recursive_wrapper<T> and then the user
would have to check whether it's nulled. This avoids the
need for BOOST_ASSERT; however it does violate the contract:

This "never-empty" property insulates the user from the possibility of
undefined variant content and the significant additional
complexity-of-use attendant with such a possibility.

mentioned here:

however, setting operator.p_ to NULL does the same but makes
it harder for the user to detect since the user would have to
use a try/catch to test it, IIUC.


Boost list run by bdawes at, gregod at, cpdaniel at, john at