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

From: John Meinel (boost_at_[hidden])
Date: 2004-10-30 18:34:44

> 
>>-----Original Message-----
>>From: boost-users-bounces_at_[hidden] [mailto:boost-users-
>>bounces_at_[hidden]] On Behalf Of John Meinel
>>Sent: Saturday, October 30, 2004 9:24 AM
>>To: boost-users_at_[hidden]
>>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
=:->