Subject: Re: [boost] [variant] Basic rvalue and C++11 features support
From: Larry Evans (cppljevans_at_[hidden])
Date: 2013-01-11 01:00:04
On 01/10/13 21:38, Rob Stewart wrote:
> On Jan 10, 2013, at 6:29 PM, Joel de Guzman <djowel_at_[hidden]> wrote:
>> On 1/9/13 11:03 PM, Paul Smith wrote:
>>> On Tue, Jan 8, 2013 at 8:48 PM, Peter Dimov <lists_at_[hidden]> wrote:
>>>> Paul Smith wrote:
>>>>> The only way to make everyone happy is to guarantee that a moved-from
>>>>> recursive variant is a valid variant.
>>>> Well, the performance hit from `new T` is making a lot of people
>>>> technically, this is not true. :-)
>>> Unfortunately, that's probably not the worst thing about it. The
>>> fact that it can also throw is the one that has the more subtle
>>> and far reaching consequences.
>> And that is utterly disappointing. This "conservative" move makes
>> all proxy-like objects with pointer ownership very inefficient!
>> While we are advocating pass by value!
>> So... can anyone finally give a good definition of what "valid" means?
> Validity depends upon the class in question. A smart pointer can be
> null and still valid. In your case, the class has the semantics that
> it always references a value. Changing that, to permit a null state,
> may be acceptable or it may have unacceptable side effects. Perhaps
> a new type, with the null state, can be added and used in some of
> the current contexts.
The "truly tagged" variant here:
has such a null state. When constructed with no arguments, it's in
this null state. It's "truly tagged" because there can be duplicate
bounded types distinguished only by the tag value. IOW, although:
is not valid,
is. The one thing bad about this is that to get a T1 out, you *must*
supply the value. For example:
get<0> to get the 1st T1, iff the tag is 0
and get<1> to get the 2nd T1, iff the tag is 1
otherwise, if the tag is -1, no values have been
put into the one_of_maybe, it's in the null state.
However, that's also a good thing because there has
been a problem with variants needing duplicate types:
The other bad thing about one_of_maybe is it's slower to compile than
boost variant. I'm unsure why but I'd guess it's because there's more
template meta-programming involved :(
Hope the above gives some ideas about how to solve this problem.
> That your tests passed after your changes suggests that Spirit might
> well use such a type without problem.
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk