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

_______________________________________________
C++-sig mailing list
C++-sig@[...].org
http://mail.python.org/mailman/listinfo/c++-sig