Re: [boost] Re: Variant Library: variant size and strong guaranty

From: David Abrahams (dave_at_[hidden])
Date: 2003-04-03 22:26:26

"Eric Friedman" <ebf_at_[hidden]> writes:

> While this is certainly quite implementable, I feel a bit uneasy about
> hinging variant's exception-safety guarantees on such a small point as
> whether 'void' content is allowed. I imagine it would not only make variant
> more confusing to use but also may not satisfactorily solve the problem of
> delegating the space-vs-safety decision to the user.
>
> I'm interested in feedback on this issue.

Here's the way I see the issue:

  1. Being able to maintain a sensible invariant for variant<> (ugh,
     English can rot sometimes) is important.

    b. "One or none" (i.e. maybe-empty) is a reasonable-sounding
       invariant.  Given that one has to ask what kind of contents are
       in the variant in order to do anything with them**, it's hard for
       me to imagine a case where "one or none" would be any worse
       than "exactly one".

    c. However, if someone can show code or program logic that is
       complicated by "one or none", I'm perfectly willing to accept
       that "exactly one" is a more-reasonable invariant for some or
       most applications.  Iff it's "most", including void as one of
       the variant types to achieve "one or none" functionality
       sounds quite elegant.

  2. Having a strong-guarantee assignment is NOT important, and in
     particular should never be bought at the cost of (space or time)
     efficiency.  You can see my writings on why copy/swap is a poor
     choice for "canonical assignment" for rationale.  In this case,
     the strong guarantee falls out of the implementation technique
     required to achieve "exactly one", and is not a goal in and of
     itself.  In that case, I see no problem at all that you only get
     the basic guarantee in the "one or none" case.

-Dave

** or get an exception trying to retrieve them, of course

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com