Re: [boost] [variant] Please vote for behavior (Was: Basic rvalue and C++11 features seupport)

Subject: Re: [boost] [variant] Please vote for behavior (Was: Basic rvalue and C++11 features seupport)
From: Joel de Guzman (djowel_at_[hidden])
Date: 2013-01-21 11:12:45

On 1/21/13 10:29 PM, Andrey Semashev wrote:
> On Mon, Jan 21, 2013 at 5:39 PM, Antony Polukhin <antoshkka_at_[hidden]> wrote:
>
> [snip]
>
>> II: Set operand.p_ to NULL, add BOOST_ASSERT in get operations
>>    + good performance
>>    + provides noexcept guarantee for move constructor
>>    + optimization will be used even if varinat has no type with trivial
>> default constructor
>>    + easy to implement
>>    - triggers an assert when user tries to reuse moved object
>>    - adds an empty state to the recursive_wrapper
>
> I'd prefer this option. IMHO, one of the major points of move
> semantics is optimization and moved-from objects are as good as dead
> anyway; I wouldn't even try to revive a moved-from object with
> assignment. But this is a breaking change (is it?), so it should have
> a prominent note in release notes.

No it's not (a breaking change). We don't have move prior to this patch.
The only issue is the one Paul Smith notes regarding conservative move
and that is only relevant in the extremely rare case when someone tries
to do something to a moved-from object. This notion of a "valid" state
is not clear to begin with anyway and many say it depends on the library
to define what "valid" means. The case of NaN is a very clear example
of a perfectly "valid" state similar to what we have here. To require
that an object not have such preconditions on operations after move will
have a negative impact on optimizations such as this.

Me? You know my vote. But Peter's suggestion (III) is also an acceptable
route.

Regards,
-- 
Joel de Guzman
http://www.boostpro.com
http://boost-spirit.com