[C++-sig] Re: call_method
brett.calcott at paradise.net.nz
Wed Dec 4 11:02:00 CET 2002
On Dec 01 21:00, David Abrahams wrote:
> OK, I've implemented the first part of this change in the CVS.
> The current status is:
> * Any Python object wrapping a C++ object of type T can be converted
> to a shared_ptr<U>, where U is T or any of its publicly-accessible
> base classes and U has been exposed with class_<U, ...>
> * There is no need to explicitly specify shared_ptr<T> as the holder
> in class_<T, ...>
> * The shared_ptr actually manages the lifetime of the Python object,
> so it will never be destroyed before the corresponding C++ object is
> Not implemented yet:
> * Automatic conversion of shared_ptr<T> to python (e.g. when used as a
> return type). For that, you still need to pass shared_ptr<T> to
> class_<...> as the holder, and since the old mechanism doesn't take
> advantage of the new shared_ptr deleter introspection feature yet,
> you always get a new Python object.
You could roll your own for the moment with a ustom to_python convertor
> Open questions:
> * There is some cost in code and compilation time associated with
> these automatic conversions for each class_<...> instance. Should
> users really be forced to pay for these conversions, or should they
> be explicitly requested, e.g.
> Such a function may be needed anyway, since classes that are exposed
> other than via class_<> (see, e.g. class Simple in
> libs/python/test/m1.cpp) may want to be managed via shared_ptr<>.
Anything to ease the strain on our poor compilers would be good :)
Of course, I'll be using it all the time.
> * Can we do better for "callback classes" which dispatch virtual
> functions to Python (like BaseWrap at
> than to ask users to store their own PyObject* "self" reference?
> Some opportunities we may be missing by not providing a nice base
> 1. The ability to prevent users from copying, or even creating these
> objects - which is dangerous because of the weak PyObject*
> 2. The ability to relieve users from having to touch the self
> pointer when implementing virtual function overrides (call_method
> could be a member of the base class)
> 3. The ability to convert shared_ptrs, references, and pointers to
> these classes into Python objects without creating a new Python
> object - instead we could just use the stored self pointer if we
> can detect derivationj from our special base class. I'm not very
> convinced this is useful for shared_ptr, since deleter
> introspection will allow us to retrieve the PyObject* if the
> object came from Python -- and shared_ptr<BaseWrap> shouldn't
> arise otherwise if we implement #1. However, it might be useful
> for regular pointers and references.
I've just got the latest cvs source and I'm getting my head back into
this -- give me a little time to play and I'll try and say something
> * And now, a radical notion: should we ban the use of shared_ptr<T> as
> an argument to class_<...> ?
Thanks for the new funkiness.
More information about the Cplusplus-sig