[C++-sig] weak_ptr/shared_from_this and boost.python

[a_python_coder]

>> 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
that
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
instance 
pointer. the "real" code is a complicated subject-observer tree where
destruction
of an observer causes deregistration from the subject. the problem occurs
when it
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
necessary (from 
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
construct, 
shared_from_this should return the _python_ weak_ptr


thanks
zac




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