SWIG and Callbacks

[Jim]

David Abrahams wrote:
> "Jim" <jbublitzNO at SPAMnwinternet.com> wrote in message
> news:3D0CE698.1050806 at SPAMnwinternet.com...

>>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.

> I'd really like to know what you find preferable about sip -- aside your own
> familiarity with it, of course, which for me usually counts more than any
> other single factor ;-). I'm actively developing v2 of Boost.Python and
> would really like to make it the best tool possible for this job, so it
> would be useful to know more.

I inherited sip rather than choosing it after 'careful evaluation',
and certainly familiarity is a big part of it. In fact I've only
given other alternatives a cursory look, so what I like about sip
may already be available in Boost or other packages.

The biggest plus for sip is that the 'IDL' is the h file syntax
with a few subtractions (variable names, forward declarations,
inline code, but inline methods stay), so that most of the
description file creation is easy to automate and still not
that hard to do manually for a small number of files. sip
supports most C++ h file syntax.

The other features that are helpful on large projects are the
built-in support for versioning and embedded docs (both also fairly
easy to automate), as well as support for 'platforms' and
'features'. So for example PyQt (not my project) can support Qt
from 1.4.2 through 3.0.4 with different mixes of features (with
SQL or not, QTable or not) across Windows, Linux/Unix/BSD, and
(soon) Mac, with a single set of source files, and still be
manageable by one person.

sip is flexible enough that you can handwrite code to "Pythonize"
C++ code (return a Python list or dict, or for example,
'void rgb (int&, int&, int&)' returns (int, int, int) and takes
no arguments in PyKDE), or create type substitutions/conversions
('mapped types') once and re-use them across a project. You can
do C++ with anything of course, but sip has it well-integrated
(manageable) and has support code to make it easier (arg unpacking,
object conversions, etc). IIRC, Boost might not need handwritten
C++ code quite as much.

I suppose those are a series of small advantages, but the end
result seems to me that you write less code and you do it in
fewer but well-known locations. It seems to add up to a big
difference on a large project.

Boost (IIRC) also has a big advantage in being able to bind much
more selectively. sip is easiest when binding everything in a lib
and probably takes a little more effort to be selective - you
can do it, but it isn't as 'mindless' (ie automatable) as most
sip file creation is. And of course Boost is actually
documented - no small thing.

How would you see Boost performing on a very large project -
say 10 libs, 20 classes/lib, 10 exposed methods/class (2000
methods overall)? I haven't looked at Boost in a while -
could you incorporate conditional compilation (eg versions,
features) and embed docs easily? Could you automate code
generation to some extent? The automation for generating
PyKDE is pretty crude at the moment, and in all fairness
isn't generally available, so this example would be a lot
of work using sip as it comes out of the box. Is Boost
really intended for projects of this size (there probably
aren't many), or do you have different goals for it?


Jim