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(...) ;