SWIG and Callbacks
david.abrahams at rcn.com
Mon Jun 17 10:18:12 EDT 2002
"Jim" <jbublitzNO at SPAMnwinternet.com> wrote in message
news:3D0D3223.5070500 at SPAMnwinternet.com...
> David Abrahams wrote:
> > I'd really like to know what you find preferable about sip -- aside your
> > familiarity with it, of course, which for me usually counts more than
> > 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.
Hmm, I wonder about that. The C++ type system is pretty sophisticated (to
the point of being able to represent entire compile-time programs!) and all
of the parser-based wrapping systems I've seen eventually fail to handle
some constructs I use, especially if I'm wrapping template-based code.
That's part of the reason I chose to use the compiler itself in
Boost.Python. The compiler (in theory) has no problem with C++ syntax ;-)
On the other hand, I realize there's a large category of simple C++
interfaces which can be parsed will less-than-complete machinery.
> The other features that are helpful on large projects are the
> built-in support for versioning
How so? Can you say more about this?
> and embedded docs (both also fairly
> easy to automate),
Do you mean docstring generation?
> 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.
Boost.Python works on a similar range of platforms.
I'm not sure if this configuration stuff is an appropriate job for a
wrapping system to provide specific support for; what's the argument for
integrating it with the wrapping system?
> 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.
Not sure about this; we'd need to compare specific functionality.
> I suppose those are a series of small advantages, but the end
> result seems to me that you write less code
Are you counting the IDL file? That's code, IMO.
> 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.
Can you explain what you mean by that?
> 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.
Heh, yeah. Unfortunately, documentation is often harder than coding. Even
the current official release of Boost.Python is not very well-documented.
We're working hard to correct that for v2, which is in pre-release.
> How would you see Boost performing on a very large project -
> say 10 libs, 20 classes/lib, 10 exposed methods/class (2000
> methods overall)?
Of course, these don't prove anything, since wrapping is a nontrivial job
and people quickly get invested in whatever is working for them. You *can*
wrap a large project with Boost.Python, but whether it's easier than with
> I haven't looked at Boost in a while -
> could you incorporate conditional compilation (eg versions,
It's C++; you can use #ifdef in just the same way that the rest of the C++
code surely does.
> and embed docs easily?
Docstring support is on the todo list for v2. It will be a matter of passing
a string literal to the def() function which wraps a function pointer:
.def_init(args<int>(), "Creates a Foo with the specified number of Bars")
.def("get_name", &Foo::get_name, "get the Foo's name")
.def("set_name", &Foo::set_name, "set the Foo's name")
> Could you automate code generation to some extent?
Not sure what you have in mind here. In a sense, the metaprogramming
techniques used by Boost.Python already *do* code generation.
> 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?
Yes, Boost.Python is intended for large projects. One of the largest
projects I've ever heard is using it at Lawrence Livermore Labs, for
More information about the Python-list