boost.python/class¶

class_<> statement constructs python class object.

Usually it’s included in BOOST_PYTHON_MODULE to wrap C++ class:

class A { ... };
BOOST_PYTHON_MODULE(example)
{
  class_<A>("A");
}

Also it can be used explicitly to create class instances from C++:

BOOST_PYTHON_MODULE(example1)
{
  object class_a = class_<A>("A");

  object instance_a = class_a();
}

If you want to forbid creating class instancies from python, you now must pass no_init to class_<> definition. Default, as in python, will be init with no arguments. There is no limit to number of init<>’s in the boost.python.

Abstract class

Pure virtual (abstract) class shall be wrapped with

class_< Abstract , boost::noncopyable>("Abstract", no_init);

Because if you don’t tell it that class is noncopyable, Boost.Python tries to register a converter for handling wrapped functions which handle function returning values of class type. Naturally, this has to be able to copy construct the returned C++ class object into storage that can be managed by a Python object. Since this is an abstract class, that fails.

C++ object storage

Boost.Python allows you to specify how Python objects will hold the C++ objects they wrap. You can specify that they be held by shared_ptr<T> (or any other smart pointer), in which case the library will generate converters to/from Python for shared_ptr<T>. The to_python converters will simply build a new Python object around the shared_ptr<>. You can specify that your C++ object is held by shared_ptr<U>. That allows you to hold a U object for dispatching, yet still pass shared_ptrs around in your C++ code.

If you have virtual functions you want to override in Python, you actually have to hold the T object with a derived class U which overrides the virtual functions to dispatch back to Python. In this case, class U naturally has to have access to the Python object

There are several problems with the above arrangement, but the most important one is that if you keep the shared_ptr<U> alive longer than its corresponding Python object, calls to the Python-overridable virtual functions will crash, because they’ll try to call through an invalid pointer.

Synopsis:

class_<A>("A")
    .def(init<int, int>())
    .def(...)
    ;

class_<B>("B", init<int, int>())
    .def(...)
    ;

class_<C>("C", "C's docstring", init<int, int>())
    .def(...)
    ;

class_<D>("D", "D's docstring", init<int, int>(), "__init__ doc")
    .def(...) 
    ;


class_<E>("E")
    .def(...)
    ;

class_<F>("F", no_init)
    .def(...)
    ;

class_<G>("G", "G's docstring", no_init)
    .def(...) 
    ;

class_<H>("H", "H's docstring")
    .def(...) 
    ;