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
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
