Re: Wrapping a C++ library using ?FFI
- From: D Herring <dherring@xxxxxxxxxxxxxxxxxxx>
- Date: Sun, 29 Jun 2008 12:27:59 -0400
Sohail Somani wrote:
Sohail Somani wrote:
I'm part of the way through writing some lisp gibberish that wraps a C++ library.
Ok, I've done most tricky things except for inheritance which I will tackle next. The general idea is to take the headers and generate the glue C, C++ and CFFI code. FWIW, this is how my brain works and I found it easiest to work this way.
I've attached a brain dump. It's kinda long but I would appreciate comments if you have them.
I suspect that for inheritance, the generated code will need to be more dynamic in that the cast_to_base function will need to do some sort of table lookups.
If that floats your boat, then have at it. Below, I've written a quick brain dump of why I don't think its a good long-term solution. But sometimes "worse is better".
As a quick note, ECL's "embedded C" strikes me as being cleaner than the more portable "write a C interface and a CFFI binding to the C interface". [Invoke the C++ compiler through some variant of (require :cmp) (setf compiler::*cc* "g++") (compile-file "c++binding.lisp")]
Portability gains from using the C layer are lost by the need to keep the build environment compatible with that of the C++ library. This includes getting all the include paths and #defines and other stuff 100% compatible with what the real build system uses. A little -m64 or -m32 can have far-reaching effects.
IIRC, boost::python does the best here since it is easily injected into the regular build system. Systems like SWIG require the user to scan command lines and try copying over all relevant details. And C++ template instantiation has enough bugs in real compilers that I don't trust any binding tool (other than the gccxml kludge) to get this completely bug-compatible with any
Another minus for the C layer -- its an abstraction which gains a little implementation simplicity at the cost of a little runtime performance and increased end-user pain. The cost of a C trampoline is easily calculated. But the real cost is in requiring end-users to install (the right version of) a C++ lib and then build a C interface lib (with the right flags). People may rightly say "this sounds brittle" and easily broken whenever the C++ lib is upgraded.
Taking the CFFI approach and implementing the ABI in Lisp isn't particularly brittle (C++ ABIs are already brittle); it just takes more work to set up (esp. for some compilers). As mentioned before before, the Itanium ABI [1] has been standardized for use by all x86_64 compilers (and with modifications for other 64-bit platforms). This (and what GCC/linux traditionally uses) makes the C++ calling convention exactly the same as the C convention, just with a hidden "this" parameter being passed, implicit pointer arithmetic, constructors/dtors being called, etc. Other legacy (esp MS) ABIs may require more work; [2] is an excellent reference.
[1] http://www.codesourcery.com/cxx-abi/abi.html
[2] Manual 5 on http://www.agner.org/optimize/
Later,
Daniel
.
- Follow-Ups:
- Re: Wrapping a C++ library using ?FFI
- From: Sohail Somani
- Re: Wrapping a C++ library using ?FFI
- References:
- Wrapping a C++ library using ?FFI
- From: Sohail Somani
- Re: Wrapping a C++ library using ?FFI
- From: Sohail Somani
- Wrapping a C++ library using ?FFI
- Prev by Date: CollabRx seeks brilliant engineers for an excellent e-science adventure
- Next by Date: Re: Let Over Lambda chapter 4
- Previous by thread: Re: Wrapping a C++ library using ?FFI
- Next by thread: Re: Wrapping a C++ library using ?FFI
- Index(es):
Relevant Pages
|
