Re: [boost] polymorphic containers

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
precedent.

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
think
> of the 'any' class. Not sure if the names distinguish where their uses
> differ.

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.