[C++-sig] A few questions on Boost.Python

[Jim Bosch]

On 01/23/2012 02:35 PM, Bo Jensen wrote:
> Hi,
>
> I have been looking into the best way for me to make a python wrapper for a
> C++ library. Boost.Python looks nice and seem to fit my needs, but I have a
> few questions before I dig in deep and do the implementation.
>
> What I want to do :
>
> I have a very thin header only C++ library, which is an extension on top of
> a c library i.e some of the C++ functions call functions in a C dll/so. So
> the C++ library only provides a nice way of using the C library with
> operators and overloading etc. For this library I want to make an python
> interface, which only should mimic the C++ classes and functions i.e there
> will be a 1:1 mapping.
>
> Questions :
>
> 1) Would Boost.Python be suited for such a task ?
>

Almost definitely.  For this sort of task most people use Boost.Python, 
SWIG, or the raw Python C-API.

Boost.Python is my favorite, and probably the favorite of most people on 
this list.  The Python C-API (what I think you're calling "cython") is a 
lot less automatic; you'll find yourself writing a lot more code, and 
doing a lot more memory management.  SWIG can be much more automatic if 
your C/C++ interface is sufficiently simple, but it's generally less 
safe w.r.t. memory management, it chokes on complex C++, and I find it 
much more difficult to debug.

> 2) What kind of speed can I expect ? I read somewhere that cython was much
> faster (but it seems to be less portable and flexible).
>

Note that none of these tools will work with Python interpreters other 
than the standard C one - no Jython, no IronPython.

The performance of any of these wrapper tools is largely determined by 
how often you cross the C++/Python boundary.  If you have a huge number 
of types, you may see more of a performance hit with Boost.Python or 
SWIG, because type conversions involve traversing a registry of all the 
types.  I wouldn't worry about performance of the wrapper layer unless 
you have a good reason to think you need to.

> 3) Will I experience problems with types like wchar or long long ?
>

I don't think wchar* will be automatically converted to Python str or 
unicode, the way char* is.

I'm pretty sure long long will be fine, but I have't really tested it much.

> 4) How do I link to my C library ?
>

Any of these tools will create a shared library (.dll, .so, .dylib, etc) 
that you link normally with other shared libraries.  Python will load 
that library when you import your wrapped module.

> 5) I also read that Boost.Python is not thread safe, is that true and if
> yes can it be fixed/hacked ?
>

Other people on this list know a lot more than I do about this topic.  I 
believe the answer depends on whether the multithreaded programming 
crosses the C++/Python boundary.

> 6) Regarding portability, will I have to recompile for each python version ?
>

Yes, for Python major releases (2.6 -> 2.7).  No for minor releases 
(2.7.2 -> 2.7.3).  I believe this will be more or less the same for any 
Python wrapper tool.

> 7) 64 bit is supported right ?
>

Absolutely.

> Thanks to anybody providing some insight.
>

Sure.  Good luck!

Jim