[C++-sig] Auto-Generation and BPL v2

Brad King brad.king at kitware.com
Wed Nov 6 20:42:06 CET 2002


> > Oops, I didn't finish this section of the email.  I meant to point out
> > that I don't see a way to have nested namespaces treated as modules in
> > Python through BPL:
> >
> > # itk::foo::Bar()
> > itk.foo.Bar()
> Sure there is. See
>   http://www.boost.org/libs/python/doc/v2/scope.html

Great, I'll try it.  Thanks.

> OK, it sounds like you'll need static method support... eventually.
> Though it looks like you just want submodule support from reading your
> earlier text.

Well, the static method support is pretty critical.  Almost every class in
ITK uses an object factory invoked through a static method, so there are
no public constructors.  Any suggestions on how to fake it for now?

> > This actually brings up the other main issue with automatic
> > generation.  Whenever a return_value_policy is required, CABLE will
> > have to make some assumptions, and probably just always use
> > reference_existing_object.
>   :(
> I hate the idea that you can crash things from Python.
> > Anything different would require per-method configuration, which
> > already starts to defeat the purpose of auto-generation of wrappers.
> Yes.

Unfortunately, no matter how careful we are with object lifetime
management, there is no way to prevent C++ code from deleting our objects
in a way the wrappers can't detect.  Even if the internal object refrence
keeps the C++ object around, a method call on it may delete the internal
object.  The python code author will at least have to be responsible
enough to prevent this problem.  Random code generators will always be
able to crash C++ programs :(

> > class_<A>("A", init<>())
> >   .def("StaticMethod", static_(&A::StaticMethod));
> I thought of that, too.
> > I'm not sure I'd prefer this over
> >
> > class_<A>("A", init<>())
> >   .def("StaticMethod", &A::StaticMethod, static_());
> Given the two options with parens, I definitely prefer the first one.
> And I think I prefer it overall, since it nicely associates staticness
> with the function to be wrapped.

That association is a good point.  I now prefer this syntax as well.  Do
you have a plan (and time) to implement this?  I can get started on
generating BPL input from CABLE without this support, but I'm going to
need it eventually.

> > revisit the issue.  However, I've toyed with the idea of automatic
> > down-casting of pointers to polymorphic C++ types.
> There is already some facility for that in Boost.Python. Take a look
> at libs/python/src/object/inheritance.cpp if you care. However, you
> have to register all the participating classes for this to work.

Fortunately, type registration is not a problem for generated code :)
I'll look at using that.

> > > However, if itk's smart pointers are indeed intrusive, it seems to
> > > me that you can just generate thin wrappers for your
> > > raw-pointer-returning functions which generate the smart pointer
> > > for you.  > [snip] Another approach we could consider is to
> > > arrange a way for you to say, "pointers to any classes derived
> > > from X should be converted to python this way". That requires an
> > > investment in some more Boost.Python work, so it might have to
> > > wait a little while...
> >
> > These options are definately worth my consideration, but this decision
> > will depend somewhat on the configurability decision I mentioned above.
> Which one?

I just mean how much fine-tuning CABLE should support for wrapper
generation.  The more fine-tuning, the less that is automatic.  The less
that is automatic, the more work for library authors when they change
their class interfaces.  One of the requirements I've been given for this
wrapping is that changes to a class's interface in C++ should not require
configuration file updates.


More information about the Cplusplus-sig mailing list