[C++-sig] weak_ptr/shared_from_this and boost.python
zreed1 at gmail.com
Sun Jul 8 20:09:21 CEST 2007
>> Ive been having a devil of a time trying to get boost python to do the
>> right thing when I try to manipulate C++ objects with weak pointers.
>[Nat] Maybe I'm missing something, but where in the short test case do
>you mention weak pointers?
the enable_shared_from_this template embeds a weak_ptr into XYZ, sorry if
wasnt clear. http://boost.org/libs/smart_ptr/enable_shared_from_this.html
>> /* *************************************************** */
>> #include <boost/python.hpp>
>> #include <boost/shared_ptr.hpp>
>> #include <boost/enable_shared_from_this.hpp>
>> using namespace std;
>> using namespace boost;
>> using namespace python;
>> struct XYZ
>> : public enable_shared_from_this<XYZ>
>> static shared_ptr<XYZ> construct()
>> s_instance = new XYZ;
>> shared_ptr<XYZ> xyz( s_instance );
>> // return a shared_ptr that manages the python object
>> return extract< shared_ptr<XYZ> >( object(xyz) );
>[Nat] I'm floored by the three lines above, especially that last line.
a little hackish, i agree. however, since bp does some magic with
shared_ptr deleters, the shared_ptr extracted in the the last line
is not in general the same as the one created in the line previous.
c++ objects instantiated by bp get passed to c++ with the correct deleter
set, but in this project objects are instantiated by an abstract factory
in c++ and manipulated in python.
>This feels like a modified singleton pattern. What do you want the
>lifespan of the managed XYZ object to be? If you want it to persist for
>the remainder of the program, why use shared_ptr? If you want it to
>vanish when the last outstanding reference has been dropped, why make it
>resemble a singleton?
in this case im just using s_instance as a place to stick a known-good
pointer. the "real" code is a complicated subject-observer tree where
of an observer causes deregistration from the subject. the problem occurs
comes time to iterate over elements of the tree - in returning an element to
python, it is necessary to pin the embedded weak_ptr. what i see then is a
use count of
0, a positive weak count, and an object has not been destroyed. i believe
that bp is
still creating a new shared_ptr count somewhere even though that shouldnt be
what i understand) after the way we constructed our initial shared_ptr.
>But even if you want to retain the XYZ* s_instance, why wouldn't you
>code construct() to set s_instance and then return get()? Why does the
>first case behave so very differently from every other case?
essentially thats whats happening. except that what we are really
initializing is not
s_instance, but the embedded weak_ptr. as a side effect of the gymnastics in
shared_from_this should return the _python_ weak_ptr
View this message in context: http://www.nabble.com/weak_ptr-shared_from_this-and-boost.python-tf4041746.html#a11491133
Sent from the Python - c++-sig mailing list archive at Nabble.com.
More information about the Cplusplus-sig