SWIG and Callbacks

[Jim]

Michael 'Mickey' Lauer wrote:
> 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 parse
>>your source code. Instead, the compile-time introspection capabilities of
>>C++ are exploited to automatically build wrappers from function and member
>>function pointers.

> I see. So it seems in order to get a nice object oriented Python interface,
> I can 1.) use SWIG to parse the header file and automatically produce a wrapper
>       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?

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

Basically, sip requires that you create a description file (.sip file)
from the h files you want to bind. While there isn't any documentation
as such, the entire process is pretty well described in a recent
thread on the PyKDE mailing list concerning libkdegames, and you
can use PyQt and PyKDE as examples.

I looked at Boost a while ago and it looks very nice. I've recommended
it to people basically because is *has* documentation and for a
single project with a small number of files would probably be more
efficient to use than sip, given the difficulties in learning sip and
setting up the configure/makefile framework.

On the other hand, I maintain PyKDE (I should point out I'm not the sip
author however), and for an actively maintained project with nearly a
dozen libraries and several hundred files, sip seems preferable. It's
possible to automate a lot of the *.sip file generation, including the
versioning (both PyQt and PyKDE use a single set of description files
that cover ALL supported versions).

As far as the example posted earlier in the thread, it doesn't look
like it would be a problem for sip, other than exposing the member
variables publicly seems like poor design and could lead to problems
in Python bindings if not used carefully.

The difficulty with sip is that while it's a very good tool for
general purpose use, it's maintained primarily for PyQt/PyKDE
and there hasn't been a lot of time available to generate
documentation or tools to go with it. It is open source, however,
and I'm sure plenty of support would be available for anyone
wanting to do work in the areas of docs or tools, or wanting to
use sip to generate bindings..


Jim