Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-08-21 06:45:31

From: "John Max Skaller" <skaller_at_[hidden]>
> > No, this is not an abuse of inheritance. xml_text IS-A xml_element, and
> > xml_element is fully abstract. I'm using a 'constrained' variant where
> > set of possible types is limited to those derived from a common base.
> Contradiction. If an xml_text is_a xml_element, there cannot
> possibly be any reason to constrain the derived types, and there
> cannot possibly be any reason to call it a variant, since there
> are no operations specific to the type not represented
> in the abstraction.

We're using the 'variant' term in different ways, I suppose.
variant<xml_element> in the example means 'a discriminated union that is
able to hold any object of type that is derived from xml_element.' I can use
xml_element operations on such a variant directly, or I can switch-on-type
and use xml_text-specific operations as long as the held object is a
xml_text instance.

> You need to understand what a variant is.

I know about ML discriminated unions. They can be approximated in C++ by

discriminated_union<xml_text, xml_tag> u;

but the approximation obviously isn't a real ML union since it isn't
statically checked.

My variant<> (and Kevlin Henney's boost::any) solve a different problem.
They are used to implement dynamically checked polymorphic values - the
thing you need when you're implementing a language where variables are
called $fish and $frog.

When implementing a statically-typed language such a variant doesn't provide
much benefit over void* and static_cast since you know that the language
compiler has already enforced the type safety.

I have found the non-ML, dynamically typed variant quite convenient,
especially when porting, for instance, PHP code to C++. It also enables
"poor man's typesafe vararg functions" taking std::vector<boost::any>.

Peter Dimov
Multi Media Ltd.

Boost list run by bdawes at, gregod at, cpdaniel at, john at