From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-01 20:06:25
Oh, this is spooky. I am just implementing similar functionality in v2 of
the Boost.Python library. In v1 it was called from_python.
The problem: a Python object (usually managed via a PyObject*, but in
Boost.Python managed with the wrapper class object) can in principle hold
any C++ type. A major component of the Boost.Python library's functionality
is the extraction of C++ objects from Python objects, and the wrapping of
C++ objects into Python objects.
So, should I call my from_python function variant_cast<> as well? I don't
think that reads well. In particular, I think of a cast as generally being
a peer-to-peer type transformation, whereas these "casts" are
container-to-containee transformations. I was thinking of "extract":
Now, "extract<>" might be too-general a name to use in namespace boost, but
I'm not sure that it is. I do think it works better than "variant_cast<>".
----- Original Message -----
From: "Douglas Gregor" <gregod_at_[hidden]>
Sent: Sunday, June 30, 2002 4:56 PM
Subject: Re: [boost] Re: Re: Yet another Variant class
> On Sunday 30 June 2002 03:23 pm, Itay wrote:
> > I like pretty much the comparison with auto_ptr::release(). However,
> > brings up the following question:
> > Since variant's interface is practically compatible with boost::any's,
> > don't we rename variant_cast to any_cast ?
> > This way, porting an existing code from any to variant,
> > will basically require the developer to change a single #include line
> > typedef statement.
> > -Itay
> I'd be inclined to go the other way: create variant_cast, but also supply
> boost::any overload of variant_cast that is a thin wrapper around
> The reason is one of pure naming: a variant doesn't take 'any' type, it
> any of a set of types, whereas boost::any is a variant type (an unbounded
> one) as is the variant we're discussing. Basically, I think
> a better name for all variant types whereas 'any_cast' is only suitable
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk