Differences between revisions 1 and 3 (spanning 2 versions)
Revision 1 as of 2002-09-26 20:42:03
Size: 709
Editor: MikeRovner
Comment:
Revision 3 as of 2002-11-18 20:54:56
Size: 2304
Editor: MikeRovner
Comment: added C++ object storage
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
If the class had no
`def_init(...)` calls, you now must pass `python::no_init` instead. On the
upside, you never need to call `def_init()` with no arguments, since that's
the default. So:
'''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.

'''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:'''
Line 7: Line 49:
    .def_init(args<int, int>())     .def(init<int, int>())
Line 11: Line 53:
class_<B>("B", args<int, int>()) class_<B>("B", init<int, int>())
Line 15: Line 57:
class_<C>("C", "C's docstring", args<int, int>()) class_<C>("C", "C's docstring", init<int, int>())
Line 19: Line 61:
class_<D>("D", "D's docstring", args<int, int>(), "__init__ doc") class_<D>("D", "D's docstring", init<int, int>(), "__init__ doc")
Line 39: Line 81:
}}}

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.

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

boost.python/class (last edited 2008-11-15 13:59:47 by localhost)

Unable to edit the page? See the FrontPage for instructions.