Re: [Boost-users] shared_ptr<> w/ Boost::Python

30 Oct 2004

      ...
...
-----Original Message-----
From: boost-users-bounces@lists.boost.org [mailto:boost-users-
bounces@lists.boost.org] On Behalf Of John Meinel
Sent: Saturday, October 30, 2004 9:24 AM
To: boost-users@lists.boost.org
Subject: [Boost-users] shared_ptr<> w/ Boost::Python
[...]
...
...
" No to_python (by-value) converter found for C++ type: class
boost::shared_ptr<class mine> "
I have a converter for "class mine". I actually thought that the
lifetime managers were using a shared_ptr, so if I did it myself, it
would just be transparent.
[Nat] We tell boost::python the smart pointer type we're using, like
this:
class_<DrawableInterface, DrawablePtr, boost::noncopyable>
("DrawableInterface", no_init)
    ;
where DrawablePtr is a typedef for the smart pointer type.
This does work, if done by itself. I can do:

class_<mine, boost::shared_ptr<mine>, bases<parent>
	, boost::noncopyable>("mine", no_init)

However, this class has virtual functions. And while not strictly 
required, I tried to follow the recommendation that you create wrappers 
for all the functions, so that you can sub-class the C++ object in python.

So I already have a class of:

class mine_w : public mine
{
public:
	PyObject *self;
	mine_w(PyObject *_self) : self(_self) {}
	virtual bool func1(int a) {
		return call_method<bool>("func1", a);
	}
}

So right now, by definition looks like:
class_<mine, mine_w, boost::noncopyable>("mine", no_init);

If I changing mine_w to shared_ptr<mine> allows it to work. But trying 
to do:
class_<mine, boost::shared_ptr<mine_w>, bases<parent>
	, boost::noncopyable>("mine", no_init);

Again complains about no to-python converter for the given type.

And trying to supply both, with:
class_<mine, boost::shared_ptr<mine>, mine_w, bases<parent>
	, boost::noncopyable>("mine", no_init);

Complains that I have too many template arguments.

Also, what about the (hypothetical) situation where I might return 
shared_ptr<mine> from one function, but auto_ptr<mine> from another?

Also, another "bug". If I create a pure-virtual class, then I should set 
the no_init field. However, if I try to sub-class this object in Python, 
the C++ constructor cannot be called, and so I can't pass this object to 
C++ functions. I'm trying to create some opaque interface classes 
(callbacks, etc). Without a wrapping class, it won't compile without 
no_init, since it tries to compile a function that would generate one. 
With a wrapping class I don't need no_init, and if I put it, then I 
can't properly subclass my object.

Are these just known problems, and people live with it, or has it just 
not really come up?

John
=:->