From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-11-17 07:48:54
From: "ERICSSON,JOHAN (A-Sonoma,ex1)" <johan_ericsson_at_[hidden]>
> My only qualm would be that I would prefer that it didn't have a default
> constructor, for the same reasons as I mentioned for poly_ptr. Its no fun
> having to do "if (p.get()) p->DoSomething()" all over the place.
Tradeoffs, tradeoffs. 'any' does have a default constructor, to name a
It's sometimes very useful to defer the initialization; default-constructing
a variant<> is way more efficient than copying a dummy value; and when you
need to construct a variant<> from a persistent store (using f.ex. an
appripriately crafted operator>>) it needs to be default-constructible.
There's no reason to do if(p.get()) p->DoSomething(). If you don't ever
create empty variants, p->DoSomething() is enough (it will BOOST_ASSERT - in
its final form, that is.)
This sounds like a good policy application except that it's not easy to
enable/disable a specific constructor using a policy. ;-)
> Also, not sure if variant is the right name. When I think 'variant', I
> of the 'any' class. Not sure if the names distinguish where their uses
variant<T> is a 'bounded-by-inheritance' variant, as opposed to any (it's an
unbounded variant) or to a discriminated union (it's bounded by a concrete,
finite set of types.)
variant<void> is (very) similar to any.
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk