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
> > 1. The source supplies almost NO type information describing what types
> > 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
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
> it will probably be named "variant", so we run the risk of confusion: it
> be clear that "variant_cast" works with "variant", but why does it work
> "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