...

-----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", no_init) ;

where DrawablePtr is a typedef for the smart pointer type.

This does work, if done by itself. I can do: class_("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", no_init); If I changing mine_w to shared_ptr<mine> allows it to work. But trying to do: class_, 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", 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 =:->