From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-06-30 12:36:38
On Saturday 29 June 2002 03:26 pm, Itay Maman wrote:
> >I'm happy with that. Personally, I would strongly
> >discourage the use of variant_cast anyway because it
> >is the only mechanism to access a variant that is
> >not guaranteed to succeed at run-time. Visitors are
> >typesafe as would be a switch-on-type construct.
> (Following this line) Then, what do you think about
> getting rid of variant_cast? This, obviously,
> contradicts the "variant with an any-like interface"
> feature, but it might have one major positive effect:
> It requires any-based code to be rewritten in a safer
If boost::any didn't exist I might agree. But boost::any has been around for
quite a while and there has been no alternative variant type in Boost. I'm
afraid that there are many users using boost::any as the variant type now in
progress. Would the omission of variant_cast make the conversion from
boost::any to variant too involved, such that users won't bother?
The other question is whether there are cases where variant_cast really is
useful. For instance, the context may dictate that only one of the types in
the variant is legal. I have come across this case a few times recently in my
So I guess I'm backing away from my current statement. I think that
variant_cast is a lot like std::auto_ptr::release: it's powerful, maybe a
little dangerous, but necessary for some cases. We should strongly encourage
the use of the safer access methods (visitor & typeswitch), but supply
variant_cast for those corner cases that need it.
> >1) Great Stack_Holder::swap :)
> >>I am wondering if there's a more efficient way for
> >>implementing an exception-safe swap() ?
> >For the general case, I don't think there is. There
> >are tons of optimization opportunities for special
> > 1) Same type: cast and swap
> > 2) Both incomplete types: swap pointers
> > 3) Both POD types: swap the bytes
> Il'l add this to my "to do" list
Maybe at the bottom :). You can be assured that variant would never be held
back in a formal review for lack of optimizations, and these optimizations
could be added later without any effect on the interfaces.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk