[SciPy-user] [Nipy-devel] how to wrap C++

Travis Oliphant oliphant.travis at ieee.org
Sat Jan 27 02:39:50 CST 2007


Mark Heslep wrote:
>>> ). Before the original C++ package ceased it's
>>> evolution (a couple of years ago) one of the developers had gotten about
>>> halfway through using Boost to provide a python interface. I did a
>>> little bit of work with SWIG a few years ago but for a very small
>>> package. So we're not sure whether to try and complete the original
>>> effort (using newer versions of python and Boost) or to start over with
>>> a currently more appropriate choice. Any thoughts welcome, thanks,
>>>     
>>>       
>> What I recall from a while ago, as relayed by John Hunter (matplotlib)
>> and Prabhu Ramachandran (mayavi) was that while boost was great, the
>> compile times and the resulting binary library sizes were completely
>> out of control.  All that templating forces instantiation of an
>> enormous number of classes, which makes both time and size explode, to
>> the point of making both development and distribution seriously
>> problematic.  Both John and Prabhu decided to go with other
>> alternatives due to this, I think it was SWIG (whose C++ support has
>> greatly improved).
>>   
>>     
> A bit of redirect here: If the OP had been talking about an existing C 
> lib and not C++, would the recommendation be 'always reach first for 
> Ctypes'? It seems too easy and direct to waste time elsewhere.
>
>   
It still depends a little.  A large library is probably more easily 
handled with SWIG, but for custom interfaces I would say ctypes is best. 

The only problems with ctypes are

1) Not easy to distribute the source code with the interface as you 
can't use distutils out of the box for building shared libraries.
2) Doesn't work with C++ code
3) Automatic-generation of the interface file is not as sophisticated as 
f2py....

-Travis

> -Mark
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-user
>
>
>   



More information about the SciPy-user mailing list