SWIG and Callbacks

David Abrahams david.abrahams at rcn.com
Sun Jun 16 16:07:34 CEST 2002

"Michael 'Mickey' Lauer" <mickey at tm.informatik.uni-frankfurt.de> wrote in
message news:3d0c6d67 at nntp.server.uni-frankfurt.de...
> David Abrahams <david.abrahams at rcn.com> wrote:
> > With Boost.Python, what you write looks like a kind of IDL (interface
> > description language), which just happens to be built out of C++ source
> > code. Lots of jobs (function argument type checking, conversion, arity
> > checking) are done automatically, but the library doesn't decide which
> > elements to wrap. Unlike SWIG and a few others, there's no attempt to
> > your source code. Instead, the compile-time introspection capabilities
> > C++ are exploited to automatically build wrappers from function and
> > function pointers.
> I see. So it seems in order to get a nice object oriented Python
> I can 1.) use SWIG to parse the header file and automatically produce a
>       1.1.) and then use this low-level wrapper to write some high-level
python classes around it or
>       2.) use Boost.Python and do the two steps in one by writing a
"handcrafted" interface?

I have no deep familiarity with SWIG, so I really don't know it takes to
produce high-level classes on the Python side with that tool. If you use
Boost.Python, you do get true classes on the Python side which are wrapped
around your C++ classes.

> How would sip come into this picture? Is it more like SWIG for C++ or more
like Boost.Python?
> (Apart from not beeing concerned about the total lack of documentation ;)

I wrote this page more than a year ago; it's surely out-of-date:


Someone needs to freshen it up for the upcoming release of Boost.Python v2;
Since you seem to be doing a survey, would you care to volunteer?


More information about the Python-list mailing list