Re: Wrapping a C++ library using ?FFI

D Herring wrote:
Sohail Somani wrote:

I don't believe there are any examples of using ECL with a non-trivial C++ library. I would like to see it though. Anyway, I don't use ECL.

Agreed; I've just started using ECL in the past couple of weeks, simply to embed it in existing C++ apps. Look (or bug me) for a tutorial-style writeup in a few weeks.

This is me and the thousands upon thousands of potential Lisp users asking you for a tutorial-style writeup in a few weeks.

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.

I agree. Hopefully it shouldn't be too much of a problem.

YMMV.

I've more or less tamed the portable builds problem so I am less concerned about portable builds than I am about portable code.

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.

Not sure I understand what you are getting at here. Any sane build system lets you factor out the common flags.

Some systems just use a few common flags. Others...

*shudder*

I didn't say they weren't happy with templates -- I said they have subtle quirks. Template instantiation rules are complicated. Many headers (e.g. Boost.org) detect compiler-specific #defines to determine which interface to export. Such subtleties may arise in corner cases; but the C layer should handle most of them.

This is the advantage of using a C layer. The C++ compiler handles it all for us.

True. Though if the C++ library maintains binary compatibility, it isn't a problem.

Few C++ libraries maintain binary compatibility. Even GNU's implementation of libstdc++ has some ABI issues between versions (my favorite affects std::string and only activates when a string is copied via one code path).

I don't know exactly what you are talking about but inlined code cannot have any hope of binary compatibility.

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).

I don't see how understanding the intricacies of an ABI are any less brittle (from the point of view of conforming to them!)

From what I recall, even g++ broke its own ABI a few times.

ABI issues can be itemized, detected, and worked with. The largest g++ ABI change, from 2/early 3 days to the present 3.3[?]/4.x ABI, was well-documented and correlates with the release of the Itanium ABI.

You've just outlined my problem. I have no intention of letting other people break my code on their own whims.

I'd like to see all full, uncompromising C++ ABIs implemented in Lisp, but I am *definitely* not interested enough to make it so (nor am I holding my breath!)

Hence, I prefixed my message with a "then have at it". :)

Indeed you did :-)

Hopefully it will only take another year or two before "the better" solution is generally available.

I would be very happy to use this once available (and if it was portable to most major compiler ABIs.)

Sohail
.

Relevant Pages

  • Re: Wrapping a C++ library using ?FFI
    ... 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. ... And C++ template instantiation has enough bugs in real compilers that I don't trust any binding tool to get this completely bug-compatible with any ... Taking the CFFI approach and implementing the ABI in Lisp isn't particularly brittle; it just takes more work to set up (esp. ...
    (comp.lang.lisp)
  • Re: Parameter Passing via a Stack
    ... the ARM9 processor recommends Core ... the question arises if the compilers were following ... the C Standard instead. ... Each platform does tend to have an Application Binary Interface (ABI) standard, and compilers/linkers are expected to conform to that. ...
    (comp.lang.c)
  • Re: Calling asm from C
    ... char vendorbuf; ... *must* agree with the ABI that the assembler routine expects. ... I've been assuming that "Intel ABI" means something... ... If the C compilers are going to get all random on us, ...
    (alt.lang.asm)
  • Re: Wrapping a C++ library using ?FFI
    ... the more portable "write a C interface and a CFFI binding to the C interface". ... People may rightly say "this sounds brittle" and easily broken whenever the C++ lib is upgraded. ... implementation of libstdc++ has some ABI issues between versions. ... for use by all x86_64 compilers. ...
    (comp.lang.lisp)
  • Re: [INFO] Kernel strict versioning
    ... As long as we want to guarantee abi, we must use the same names. ... > Get the module into the kernel. ... on compatibility with the ``major second number''. ...
    (Linux-Kernel)