|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2003-08-30 10:24:56
"Eric Friedman" <ebf_at_[hidden]> writes:
> To see why this is a problem, we need to look back at the motivation for
> variant. Apart from efficiency, one of the significant advantages of using
> variant instead of boost::any is improved type safety, specifically at
> compile-time. Indeed, the visitation mechanism forces the user to handle
> every possible type of content. If we then go ahead and allow the
> possibility of the above "empty" state (to be distinguished from
> boost::empty content), we greatly complicate these semantics. Are we to say
> that anytime a variant is involved in a failed assign/swap operation,
> visitation will subsequently fail -- but only at runtime?
I understand again, thanks for reminding me. But as I mentioned
earlier, this rationale *needs* to be in the variant docs.
One possible approach is to say that variant assignment from one type
to another may incur dynamic allocation (**). Negative "which" values
mean that the storage is really holding a pointer to the actual
object.
(**) You can specify it so that there are many ways to avoid that
allocation:
- include a type known to be nothrow default constructible
- all types are known to have nothrow copy ctors
- never assign from one kind of variant into another kind
- all types are known to have a nothrow swap
- ...
I don't love this solution, but it's an idea.
-- 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