[C++-sig] Re: call_method

[Brett Calcott]

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

Very cool.

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

> 
> 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.
> 
>      register_shared_ptr<T>();
> 
>   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
>   http://www.boost.org/libs/python/doc/tutorial/doc/class_virtual_functions.html)
>   than to ask users to store their own PyObject* "self" reference?
>   Some opportunities we may be missing by not providing a nice base
>   class:
> 
>   1. The ability to prevent users from copying, or even creating these
>      objects - which is dangerous because of the weak PyObject*
>      reference.
> 
>   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
sensible.

> 
> * And now, a radical notion: should we ban the use of shared_ptr<T> as
>   an argument to class_<...> ?
>   

As above..

Thanks for the new funkiness.

Cheers,
Brett