Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-10-10 12:46:21


From: "Douglas Gregor" <gregod_at_[hidden]>
> On Wednesday 10 October 2001 11:37, you wrote:
> > Interesting naming problem. This "cast" has a few interesting
properties:
> >
> > 1. The source supplies almost NO type information describing what types
may
> > be "cast-to".
> > 2. The result object is in some sense "contained" in the source.
> > Any others?
> >
> > I'm not sure how relevant (2) is, but the combination of 1&2 leads me to
> > like "extract<T>(source)".
>
> I could live with "extract<T>(source)", but I wonder if it would be more
> precise to use something like "variant_cast<T>(source)"?

FWIW, extract<> and variant_cast<> are the two names I considered myself. I
use variant_cast<> for my variant<> (following the any_cast convention) but
the name seems generic enough to be usable for 'any', function, and the
future discriminated union.

OTOH when I need to extract a value from a variant (i.e. the extraction
cannot fail, as I know that the variant contains exactly the type I need) I
usually define extract<>.

For example, when I need to make a wrapper for int (*f) (int, double) that
can be assigned to boost::function<any, vector<any> >, I usually use
'extract.'

When I use the idiom

if(int * p = any_cast<int>(&a))
{
// handle ints
}

I prefer variant_cast as this notation doesn't really extract.

> My only concern with
> the name "variant_cast" is that if (when?) we do get a bounded variant
class,
> it will probably be named "variant", so we run the risk of confusion: it
will
> be clear that "variant_cast" works with "variant", but why does it work
with
> "function" and "any"?

This is a generic argument against anything ending in _cast. Suppose that we
define a class named 'dynamic.' Does this mean that dynamic_cast shouldn't
be named dynamic_cast? ;-)

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