c++boost.gif (8819 bytes)
Comparisons with Other Systems

CXX

Like Boost.Python, CXX attempts to provide a C++-oriented interface to Python. In most cases, as with the boost library, it relieves the user from worrying about reference-counts. Both libraries automatically convert thrown C++ exceptions into Python exceptions. As far as I can tell, CXX has no support for subclassing C++ extension types in Python. An even more significant difference is that a user's C++ code is still basically ``dealing with Python objects'', though they are wrapped in C++ classes. This means such jobs as argument parsing and conversion are still left to be done explicitly by the user.

CXX claims to interoperate well with the C++ Standard Library (a.k.a. STL) by providing iterators into Python Lists and Dictionaries, but the claim is unfortunately unsupportable. The problem is that in general, access to Python sequence and mapping elements through iterators requires the use of proxy objects as the return value of iterator dereference operations. This usage conflicts with the basic ForwardIterator requirements in section 24.1.3 of the standard (dereferencing must produce a reference). Although you may be able to use these iterators with some operations in some standard library implementations, it is neither guaranteed to work nor portable.

As far as I can tell, CXX enables one to write what is essentially idiomatic Python code in C++, manipulating Python objects through the same fully-generic interfaces we use in Python. While you're hardly programming directly to the ``bare metal'' with CXX, it basically presents a ``C++-ized'' version of the Python 'C' API. Some fraction of that capability is available in Boost.Python through boost/python/objects.hpp, which provides C++ objects corresponding to Python lists, tuples, strings, and dictionaries, and through boost/python/callback.hpp, which allows you to call back into python with C++ arguments.

Paul F. Dubois, the original author of CXX, has told me that what I've described is only half of the picture with CXX, but I never understood his explanation well-enough to fill in the other half. Here is his response to the commentary above:

``My intention with CXX was not to do what you are doing. It was to enable a person to write an extension directly in C++ rather than C. I figured others had the wrapping business covered. I thought maybe CXX would provide an easier target language for those making wrappers, but I never explored that.''
-Paul Dubois

SWIG

SWIG is an impressively mature tool for exporting an existing ANSI 'C' interface into various scripting languages. Swig relies on a parser to read your source code and produce additional source code files which can be compiled into a Python (or Perl or Tcl) extension module. It has been successfully used to create many Python extension modules. Like Boost.Python, SWIG is trying to allow an existing interface to be wrapped with little or no change to the existing code. The documentation says ``SWIG parses a form of ANSI C syntax that has been extended with a number of special directives. As a result, interfaces are usually built by grabbing a header file and tweaking it a little bit.'' For C++ interfaces, the tweaking has often proven to amount to more than just a little bit. One user writes:

``The problem with swig (when I used it) is that it couldnt handle templates, didnt do func overloading properly etc. For ANSI C libraries this was fine. But for usual C++ code this was a problem. Simple things work. But for anything very complicated (or realistic), one had to write code by hand. I believe Boost.Python doesn't have this problem[sic]... IMHO overloaded functions are very important to wrap correctly.''
-Prabhu Ramachandran

By contrast, Boost.Python doesn't attempt to parse C++ - the problem is simply too complex to do correctly. Technically, one does write code by hand to use Boost.Python. The goal, however, has been to make that code nearly as simple as listing the names of the classes and member functions you want to expose in Python.

SIP

SIP is a system similar to SWIG, though seemingly more C++-oriented. The author says that like Boost.Python, SIP supports overriding extension class member functions in Python subclasses. It appears to have been designed specifically to directly support some features of PyQt/PyKDE, which is its primary client. Documentation is almost entirely missing at the time of this writing, so a detailed comparison is difficult.

ILU

ILU is a very ambitious project which tries to describe a module's interface (types and functions) in terms of an Interface Specification Language (ISL) so that it can be uniformly interfaced to a wide range of computer languages, including Common Lisp, C++, C, Modula-3, and Python. ILU can parse the ISL to generate a C++ language header file describing the interface, of which the user is expected to provide an implementation. Unlike Boost.Python, this means that the system imposes implementation details on your C++ code at the deepest level. It is worth noting that some of the C++ names generated by ILU are supposed to be reserved to the C++ implementation. It is unclear from the documentation whether ILU supports overriding C++ virtual functions in Python.

GRAD

GRAD is another very ambitious project aimed at generating Python wrappers for interfaces written in ``legacy languages'', among which C++ is the first one implemented. Like SWIG, it aims to parse source code and automatically generate wrappers, though it appears to take a more sophisticated approach to parsing in general and C++ in particular, so it should do a much better job with C++. It appears to support function overloading. The documentation is missing a lot of information I'd like to see, so it is difficult to give an accurate and fair assessment. I am left with the following questions:

Anyone in the possession of the answers to these questions will earn my gratitude for a write-up ;-)

Zope ExtensionClasses

ExtensionClasses in Zope use the same underlying mechanism as Boost.Python to support subclassing of extension types in Python, including multiple-inheritance. Both systems support pickling/unpickling of extension class instances in very similar ways. Both systems rely on the same ``Don Beaudry Hack'' that also inspired Don's MESS System.

The major differences are:

Next: A Simple Example Using Boost.Python Previous: A Brief Introduction to writing Python Extension Modules Up: Top

© Copyright David Abrahams 2000. Permission to copy, use, modify, sell and distribute this document is granted provided this copyright notice appears in all copies. This document is provided ``as is'' without express or implied warranty, and with no claim as to its suitability for any purpose.

Updated: Mar 6, 2001