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.
** or get an exception trying to retrieve them, of course
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk