|
Boost : |
Subject: Re: [boost] [variant] Basic rvalue and C++11 features support
From: Larry Evans (cppljevans_at_[hidden])
Date: 2013-01-11 08:34:32
On 01/11/13 00:17, Joel de Guzman wrote:
> On 1/11/13 2:00 PM, Larry Evans wrote:
>> On 01/10/13 21:38, Rob Stewart wrote:
[snip]
>>> 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:
>>
>> http://svn.boost.org/svn/boost/sandbox/variadic_templates/boost/composite_storage/pack/container_one_of_maybe.hpp
>>
>>
>> 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:
>
> Larry, sorry, but that's irrelevant. We are talking about recursive_wrapper
> here, not variant.
>
> Regards,
OK, I probably was jumping to conclusions, but from looking at:
which contained:
typedef boost::variant<
int
, boost::recursive_wrapper< binary_op<add> >
, boost::recursive_wrapper< binary_op<sub> >
> expression;
I concluded that recursive_wrapper always occurred in a variant.
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.
Sorry if I misunderstood, but it seemed reasonable suggestion
at the time.
-regards,
Larry
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk