[pypy-dev] missing things for making PyPy "production" ready (for some value of production)
david at ar.media.kyoto-u.ac.jp
Mon Nov 19 08:01:34 CET 2007
Amaury Forgeot d'Arc wrote:
> wxPython has the same number of functions, and uses Swig to do the wrapping.
swig parses C++ headers, and basically a significant part of C++. There
is really no way to do any kind of wrapping of C++ without parsing it,
or at least a significant portion of it.
> This is not necessary, and sometimes not suitable.
> With Swig for example, the syntax for classes and function
> declarations is indeed based on C++, but you often need a lot of
> tweaks to make it generate code that will work properly. These are
> called "typemap", "extend", "director" and other "features", and these
> additional directives are not C++.
> Swig uses an internal representation of the parsed file, which can be
> dumped to XML for example. It is possible to imagine another way to
> create the same representation and have the same wrapper generated. Of
> course I have something like rffi in mind...
Swig has been in development for more than 10 years now. And the C++
part is extremely difficult. As said in swig doc themselves:
Because of its complexity and the fact that C++ can be difficult to
integrate with itself let alone other languages, SWIG only provides
support for a subset of C++ features. Fortunately, this is now a rather
In part, the problem with C++ wrapping is that there is no semantically
obvious (or automatic ) way to map many of its advanced features into
other languages. As a simple example, consider the problem of wrapping
C++ multiple inheritance to a target language with no such support.
Similarly, the use of overloaded operators and overloaded functions can
be problematic when no such capability exists in a target language.
> I don't think that Swig itself can be used by pypy, I just wanted to
> show that automatic wrapping of C++ is possible and can be used by
> pypy, without the help of ctypes.
My point is not that it is impossible to wrap C++ (doing with ctypes is
impossible anyway, by the way: ctypes does not support C++), but:
- C++ is significantly harder than C to wrap
- A ffi for C++ is incredibly harder than C
- Supporting C could already go towards a production ready pypy. C++
is certainly a nice add-on, but less important than C.
I also actually think the swig approach to be quite useful, and maybe
the path of least effort: C++->C wrapper, and then wrap C using ctypes:
if the swig internal representation is reusable (although I have some
experience with C++ and swig, I never tried the dump option you are
talking about), then most of the work is done.
More information about the Pypy-dev