class derivation in boost.python v2. Was Re: [C++-sig] Lifetime ofPython object for a pointer argument
David Abrahams
david.abrahams at rcn.com
Sun Feb 17 23:39:15 CET 2002
Thanks, that's one bug of mine and one of yours. I've fixed mine -- it was
crashing instead of properly reporting your error. You need to wrap the base
class (A) before you wrap the derived (AA). I know it looks like you are,
but don't forget there's no sequence point in that chain of calls to
guarantee argument initialization order in C++. The correct module is:
BOOST_PYTHON_MODULE_INIT(AA)
{
python::module m("AA");
m.add(
python::class_<A>("A")
.def_init()
);
m.add(
python::class_<AA, bases<A> >("AA")
.def_init(args<const A&>())
)
;
}
You don't need the try/catch block ;-)
(Aside) How did you build bpl.so? If you use the debug-python build (the
default in libs/python/Jamfile), you need a Python configured
with --with-pydebug. Otherwise, you need the "debug" or "release" builds of
bpl.
----- Original Message -----
From: "Min Xu" <minxu at sci.ccny.cuny.edu>
To: <c++-sig at python.org>
Sent: Sunday, February 17, 2002 11:26 AM
Subject: class derivation in boost.python v2. Was Re: [C++-sig] Lifetime
ofPython object for a pointer argument
> > Unfortunately, those features aren't specifically implemented in v2 yet.
> > Operators are supported in the usual Python way (i.e. you can expose an
> > __add__ function), but the automatic wrapping features of v1 are not yet
> > available. I have not yet decided where this fits in the development
plan.
> > If you wanted to contribute some code it would be very much appreciated,
of
> > course.
> I hope so.
>
> >
> > Enums can be exposed as ints using the techniques with which scalars are
> > exposed in libs/python/src/converter/builtin_converters.cpp, but that
code
> > was mostly written to be implementation detail. I guess I need to clean
up
> > and document most of those classes so that users can take advantage of
them.
> >
> > However, I think I've come to *yet another* realization about how the
> > low-level from_python conversion mechanism should work, so I guess I
will be
> > re-engineering most of what's in builtin_converters.cpp at some point in
the
> > next month or so; you might not want to invest in understanding that.
> >
> I redefine the enumeration as int as a temporal solution.
>
> > Finally, <redfaced>I just realized that I haven't yet implemented the
use of
> > CallPolicies in __init__ functions</redfaced>, so this won't compile:
> >
> > .def_init(args<const grid*>()
> > // Keep the grid alive as long as the geometry is.
> > , python::with_custodian_and_ward<1,2>())
> >
> > Give me at least until Monday to take care of that.
> >
> Thanks. However the following bug may be more severe. A very simple code
> is as following. It compiles yet makes python2.2 core dump.
>
> #include <boost/python/module.hpp>
> #include <boost/python/class.hpp>
>
> class A
> {
> public:
> A() : x(0) {}
> A(const A& a) : x(a.x) {}
> private:
> double x;
> };
>
> class AA : public A
> {
> public:
> AA(const A& a) : A(a) {}
> };
>
> namespace python = boost::python;
>
> BOOST_PYTHON_MODULE_INIT(AA)
> {
> try
> {
> python::module("AA")
> .add(
> python::class_<A>("A")
> .def_init(args<>())
> )
> .add(
> python::class_<AA, bases<A> >("AA")
> .def_init(args<const A&>())
> );
> }
> catch(...)
> {
> file://python::handle_exception(); // Deal with the exception for
Python
> }
> }
>
> g++ -I/usr/local/include -I/usr/include/python2.2 -c -Wall
> -ftemplate-depth-100 -DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_V2 -g
> -O0 -fno-inline -fPIC tst.C
> g++ -g -fpic -shared -o AA.so -L/usr/lib/python2.2/config
> -I/usr/include/python2.2 -I/usr/local/include tst.o -lutil -lbpl
>
> And in python2.2:
> >>> import AA
> Segmentation fault (core dumped)
>
>
> Min Xu
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
More information about the Cplusplus-sig
mailing list