On 01/30/13 00:32, Jeffrey Lee Hellrung, Jr. wrote:
On Tue, Jan 29, 2013 at 1:34 PM, Markus Klein <markus-klein@live.de> wrote:
On Fri, Jan 25, 2013 at 10:21 AM, Dave Abrahams <dave@boostpro.com> 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: http://www.boost.org/doc/libs/1_52_0/doc/html/boost/make_recursive_variant.h... ). 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 functions). Thoughts? -regards, Larry