Boost logo

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