views:

203

answers:

2

I have a library which creates objects (instances of class A) and pass them to a python program which should be able to call their methods.

Basically I have C++ class instances and I want to use them from python. Occasionally that object should be passed back to C++ for some manipulations.

I created the following wrapper file (let's assume that the New function is called somewhere in the C++ code):

#include <boost/python.hpp>
#include <iostream>
#include <boost/smart_ptr.hpp>

using namespace boost;
using namespace boost::python;

int calls = 0;

struct A
{
   int f() { return calls++; }
   ~A() { std::cout << "destroyed\n"; }
};

shared_ptr<A> existing_instance;

void New() { existing_instance = shared_ptr<A>( new A() ); }

int Count( shared_ptr<A> a ) { return a.use_count(); }

BOOST_PYTHON_MODULE(libp)
{
    class_<A>("A")
        .def("f", &A::f)
    ;

    def("Count", &Count);

    register_ptr_to_python< shared_ptr<A> >();
} 

The code lacks the part where the python gets the existing_instance. I didn't paste that, but let's just say I use a callback mechanism for that purpose.

This code works but I have a few questions:

  1. In the Count function (and in all other C++ manipulation functions) is it fine to pass a like that or it's better to do something like const shared_ptr<A>&? In the code snippets I found in the python boost documentation the reference is often used but I don't understand the difference (apart from having a higher reference counter, of course).

  2. Is this code "safe"? When I pass the existing_instance to python, its counter will be incremented (just once, even if in python I make more copies of the object, of course) so there is no way that the C++ code could destroy the object as far as python holds at least a "copy". Am I correct? I tried to play with pointers and it seems I'm correct, I'm asking just to be sure.

  3. I'd like to prevent python from creating instances of A. They should only be passed from C++ code. How could I achieve that? EDIT: found, I just need to use no_init and noncopyable: class_<A, boost::noncopyable>("A", no_init)

+1  A: 

In this situation my code would look like this (for your example):

...

BOOST_PYTHON_MODULE(libp)
{
    class_<A, boost::shared_ptr<A>, boost::noncopyable >("A")
       .def("f", &A::f)
       .def("Count", &Count)
     ;
 } 

It is important to forbid boost::python to copy things, but if your are using shared_ptr chances are that you only need copying in a few controlled situations.

dignor.sign
+2  A: 

boost::python knows all about boost::shared_ptr, but you need to tell it that boost::shared_ptr<A> holds an instance of A, you do this by adding boost::shared_ptr<A> in the template argument list to class_, more information on this 'Held Type' is here in the boost documentation.

To prevent instances being created from python, you add boost::python::no_init to the class_ constructor, so you end up with:

boost::python::class_< A, boost::shared_ptr<A> >("A", boost::python::no_init)
    //... .def, etc
    ;

In general you should not pass around shared pointers by reference, since if the reference to the shared pointer is invalidated, then the reference to which the shared pointer is pointing to is also invalidated (since taking a reference of the shared pointer didn't increment the reference counter to the pointed to object).

It is perfectly safe to pass boost::shared_ptr objects around to and from python, reference counts (python and shared_ptr) will be correctly managed provided you don't change the return_value_policy. If you change the policy of a method exposed in python so that it returns a reference to a shared pointer then you can cause problems, just as passing shared pointers around be c++ references can cause problems.

(Also, you should use make_shared<A>(...) in preference to shared_ptr<A>(new A(...)).)

Autopulated
what's the difference (in practice) between "class_<A, boost::noncopyable>("A", no_init)" and "boost::python::class_< A, boost::shared_ptr<A> >("A", boost::python::no_init)" ?The code I posted works perfectly even without specifying "boost::shared_ptr<A>" after "class_". So why would I need that?
happy_emi
It specifies the default type that will actually be wrapped by a python 'A' - so if you have a c++ function that returns an 'A', 'A*' shared_ptr<T> or anything similar, and expose it to python, then the return value will be held as a shared_ptr<A> - which if what you want if you are frequently passing these objects in and out of python, since all ownership will be correctly handled.See http://www.boost.org/doc/libs/1_43_0/libs/python/doc/v2/class.html#HeldType (esp. point 2) for more information.
Autopulated