[pypy-dev] missing things for making PyPy "production" ready (for some value of production)

David Cournapeau 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 
large subset.

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.

David



More information about the Pypy-dev mailing list