Re: [boost] [variant] Basic rvalue and C++11 features support

Subject: Re: [boost] [variant] Basic rvalue and C++11 features support
From: Larry Evans (cppljevans_at_[hidden])
Date: 2013-01-11 09:47:42

On 01/11/13 08:18, Peter Dimov wrote:
> Larry Evans wrote:
>> I further jumped to the conclusion that *if* the variant had a
>> null state, then it would not assume any of its bounded types
>> were "in effect"; hence, would not call any destructors
>> for any bounded type or perform any operations on any bounded
>> type; hence, the pointer in recursive wrapper would not even
>> need to be zeroed because the containing variant would not
>> assume that it even had a recursive_wrapper as one of its
>> bounded types.
>
> You're quite correct. The problem does not stem from inadequate tagging
> though. The problem stems from the never-empty guarantee:
>
>
http://www.boost.org/doc/libs/1_52_0/doc/html/variant/design.html#variant.design.never-empty
>
>
> If the variant could be empty, or equivalently, if the variant always
> contained a type that can be reliably default-constructed (without an
> exception) such as int, the problems with assignment (both copy- and
> move-) and with move construction do not occur, because the target can
> be left holding the int.
>
> So, one option is to enable move only in this case.
>

Are you suggesting that move is enabled only if the current tag (the
variant<*>::which() result) indicates the current type is default
constructable?

I was thinking that after the move to the target variant, the source
variant has its tag reset to something to indicate the current type is
this default constructable type and that type would be empty.  IOW,
a default contructable something like:

  special_type<nothing_id>

found here:

http://svn.boost.org/svn/boost/sandbox/variadic_templates/boost/composite_storage/special_components.hpp

IIUC, that would allow a move no matter what the current tag was,
because afterwards, the source variant would have a null state, and in
that null state, nothing could be done except during the ~variant()
call when only the variant<...>::storage_ destructor would be called.

Does that make sense?

-regards,
Larry