How much C++ do I need to know in order to wrap some else's C++ library?
C++ Language Interface Foundation (CLIF)
11–20 of 72 posts
Re: C++ Language Interface Foundation (CLIF)
#12Having used both SWIG and Boost.Python professionally, I find manual work required by the latter to be 100% worthwhile and usually necessary.
C++ and Python are not very similar, and the result of auto-binding them typically gives up a combination of fluency and performance.
A simple example of the former is a C++ algorithm which writes to an output iterator. In Python this might be expressed as a generator. But none of the auto-binding tools can do this transformation.
As for the latter--performance--I have seen 100x performance penalties in practice when the blind lead the bind. A good example is that in Python we have memoryview and the buffer protocol, but auto-binding tools take these no further than std::vector (if that). A C++ API which produces a large stream of numeric data just begs to be bound using the buffer protocol or perhaps even NumPy directly. But if a C++ API produces small values really quickly, an auto-bound one will produce the same small values really slowly.
Some people see the writing of bindings as manual labor to be avoided. I see it as an optimization opportunity. There are huge gains available.
Re: C++ Language Interface Foundation (CLIF)
#13Can this wrap Qt (or barring Qt, wxWidgets)? There are great Qt bindings in Python, but in other languages, not so much.
Re: C++ Language Interface Foundation (CLIF)
#14I wondered how long it would take before someone posted CLIF here since we haven't put up a blog post about it yet... :)
Interesting stat: Around 80% of our the Python C++ extension module wrappings being added to our code base are now being done using CLIF instead of SWIG. We are actively working on forbidding new Python SWIG wrappers from being added and migrating important legacy wrappings off of it onto CLIF.
Who am I? I am TL of the team that create CLIF (design and code reviewer, _not_ a primary author; they can identify themselves as they see fit). -gps@
Re: C++ Language Interface Foundation (CLIF)
#15How much C++ do I need to know in order to wrap some else's C++ library?
Quite a lot, or at least by proxy given that you would have to talk to library and compilers that are written in C++.
However: Some libraries/packages do expose a C api, which you could use in a language assuming it had a decent FFI.
A lot of major C++ projects use exceptions, which you will have to catch and handle inside of the C++ because even if C could catch exceptions, there is no guarantee of ABI compatibility. Some languages, I think D can do it, can catch an exception thrown in C++ code.
You might have better luck integrating a standard data interface between the C++ and any other language: However, that could be a little slow.
Re: C++ Language Interface Foundation (CLIF)
#16C++ is an extremely challenging language to write a wrapper generator for. I did a C++ to Common Lisp generator about a decade ago for my GSoC project, based on GCC-XML (with the goal of being able to wrap QT). The two challenges you run into are that the GCC C+ ABI is extremely complicated and requires a runtime on top of whatever low-level C FFI you're working with. The second is that many semantics just don't map…
It makes sense to write system APIs in C, but there are many more things than system APIs, and many of them find it useful to use C++ constructs.
(edit) Clang's internals are also several orders of magnitude easier to work with than GCC's internals. In fact, clang is designed to be used as a library, and CLIF leverages that very, very highly.
See, for example, https://clang.llvm.org/docs/ClangTools.html . Clang tools are very powerful, and much of CLIF is based on a Clang tool, not a GCC internals hack.
Re: C++ Language Interface Foundation (CLIF)
#17The repository mentions "other languages" but I could only find Python examples? While I think wrapper generators are a noble idea, I doubt I would choose this over the convenience of IDL-like metaprogramming approaches (e.g. pybind11, or Boost.Python)
CLIF is designed to support arbitrary front-end languages--and other languages are in the exploratory phases. But there is no full support for other languages at this time.
Re: C++ Language Interface Foundation (CLIF)
#18Having used both SWIG and Boost.Python professionally, I find manual work required by the latter to be 100% worthwhile and usually necessary. C++ and Python are not very similar, and the result of auto-binding them typically gives up a combination of fluency and performance. A simple example of the former is a C++ algorithm which writes to an output iterator. In Python this might be expressed as a generator. But none…
There are always justifiable use cases for manually written Python bindings.
But a "there be dragons" caveat applies as getting the CPython API correct is complicated. Reference counting and error checking bugs are common in hand written CPython C API code.
For most cross language bindings the primary goal is to "just work reliably". Optimization can happen later after you have profiles to figure out where it is worth doing and in what way.
Re: C++ Language Interface Foundation (CLIF)
#19Finally! I have been suffering under SWIG and have been hoping for some time that someone would get the compiler to do this.+ Not to say SWIG isn't an amazing effort, but it's a whole C++ compiler maintained by a very small team. + I already put my time in at the gcc salt mines so no, I didn't try doing this myself.
Perhaps the best thing about CLIF is that it never, ever, parses any C++ by hand [0]. It always uses a state-of-the-art, fully-industrial-strength, well-supported compiler: Clang. And it can be updated in lockstep with Clang near trivially.
[0] Actually, there is one tiny exception: CLIF occasionally separates a C++ qualified name on the scope-resolution operator "::".
Re: C++ Language Interface Foundation (CLIF)
#20C++ is an extremely challenging language to write a wrapper generator for. I did a C++ to Common Lisp generator about a decade ago for my GSoC project, based on GCC-XML (with the goal of being able to wrap QT). The two challenges you run into are that the GCC C+ ABI is extremely complicated and requires a runtime on top of whatever low-level C FFI you're working with. The second is that many semantics just don't map…
> All that is a roundabout way of saying: for god's sake write your system APIs in C.
Or at least expose a C-compatible ABI.