# Comparisons with Other Systems

## CXX

Like BPL, 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.

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 BPL, 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 BPL doesn't have this problem[sic]... IMHO overloaded functions are very important to wrap correctly.''
> -Prabhu Ramachandran

By contrast, BPL doesn't attempt to parse C++ - the problem is simply too complex to do correctly. Technically, one does write code by hand to use BPL. 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 BPL, 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 BPL, 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:

- Does it support overriding of virtual functions?
- What about overriding private or protected virtual functions (the documentation indicates that only public interfaces are supported)?
- Which C++ language constructs are supportd?
- Does it support implicit conversions between wrapped C++ classes that have an inheritance relationship?
- Does it support smart pointers?

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 BPL 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:

- BPL lifts the burden on the user to parse and convert function argument types. Zope provides no such facility.
- BPL lifts the burden on the user to maintain Python reference-counts.
- BPL supports function overloading; Zope does not.
- BPL supplies a simple mechanism for exposing read-only and read/write access to data members of the wrapped C++ type as Python attributes.
- Writing a Zope ExtensionClass is significantly more complex than exposing a C++ class to python using BPL (mostly a summary of the previous 4 items). A Zope Example illustrates the differences.
- Zope's ExtensionClasses are specifically motivated by ``the need for a C-based persistence mechanism''. BPL's are motivated by the desire to simply reflect a C++ API into Python with as little modification as possible.
- The following Zope restriction does not apply to BPL: ``At most one base extension direct or indirect super class may define C data members. If an extension subclass inherits from multiple base extension classes, then all but one must be mix-in classes that provide extension methods but no data.''
- Zope requires use of the somewhat funky inheritedAttribute (search for ``inheritedAttribute'' on this page) method to access base class methods. In BPL, base class methods can be accessed in the usual way by writing ```BaseClass.method`''.
- Zope supplies some creative but esoteric idioms such as Acquisition. No specific support for this is built into BPL.
- Zope's ComputedAttribute support is designed to be used from Python. The analogous feature of BPL can be used from C++ or Python. The feature is arguably easier to use in BPL.

Next: A Simple Example Using BPL 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: Nov 26, 2000