Boost logo

Boost :

Subject: Re: [boost] [variant] Please vote for behavior
From: Larry Evans (cppljevans_at_[hidden])
Date: 2013-01-30 08:23:17

On 01/30/13 00:32, Jeffrey Lee Hellrung, Jr. wrote:
> On Tue, Jan 29, 2013 at 1:34 PM, Markus Klein <markus-klein_at_[hidden]> wrote:
>> On Fri, Jan 25, 2013 at 10:21 AM, Dave Abrahams <dave_at_[hidden]> wrote:
>>> Yes. IIUC the question here is whether the invariant of variant [;-)]
>>> shall be weakened to accommodate efficient move semantics, thereby
>>> breaking some code, or not, at some cost (the specific costs to be
>>> incurred by various strategies presently under discussion).
>> I'm new to this list, so I won't be offended if you correct me on any
>> rookie
>> mistakes.
>> Concerning the invariant of variant:
>> Why not provide a specialization of boost::optional for variant, which
>> supports move
>> Semantics? Users who don't want their invariant harmed, can use
>> boost::variant as is.
>> Users who need to squeeze out performance could use an optional<variant>
>> and
>> would
>> be explicitly aware of the new null state they introduced for this.
> Why I don't think that's a particularly good idea:
> - optional< variant<blah> > doesn't have the same interface as
> variant<blah>.
> - It's a lot of syntactic noise.
> - It isn't obvious that you're using optional< variant<blah> > primarily to
> enable move semantics.
> - We can still get proper move semantics for variant in most use cases
> without ever violating the never-empty guarantee. This is only ever an
> issue for a recursive variant which is not default-constructible. The fix
> is easy: prepend your typelist with boost::blank.
Hmm... Just brainstorming here:
What about deriving the current variant from a new class,
variant_core, which didn't have all the TMP used by the current
variant for handling recursion( for example, look at all the
TMP described here:

Also, variant_core might not even need to have a never-empty
guarantee if variant_core.which() is allowed to return some
value indicating empty.

IOW, variant_core would have *less* constraints than
variant which seems consistent with the idea that
a base class has *less* constraints than the derived
class (where constraint here means either more member
variables or functions or more specific virtual



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