C++ roadmap

Luke Hutchison luke.hutch at gmail.com
Sat Aug 17 19:20:01 UTC 2019


On Mon, Aug 12, 2019 at 2:37 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> It is true that any language that want to interop with C++ has to - as
> you put it - "reinvent the wheel". There are "known issues" when it
> comes to mapping C++ down to what's understood by the ABIs, name
> mangling, templates, exceptions and the likes. Yet, at least when I
> looked, there doesn't seem to be a general solution to the problem of
> 'lowering C++' down to C (if that's what you ask); I've seen numerous
> attempts e.g. on SWIG, most of which looked promising, but never saw
> completion.
>

Yes, lowering C++ to C is exactly what I was describing -- for each
syntactic construction, generating code that mimics the semantics of that
construction, then using partial evaluation to compose these semantics into
a set of generated bindings with a simple C function interface.

I don't think this can be done for C++ without a powerful code generation
and partial evaluation framework (hence the mention of Futamura
projections), due to the complexity of C++ semantics. Writing a C++ binding
generator by hand without the use of partial evaluation is a masochistic
exercise I would never want to attempt -- and there would be an infinitely
long list of corner cases that would have to be handled, as you mentioned.
Partial evaluation would make it possible to simply write code that simply
directly interprets/evaluates/emulates the C++ syntax in question, then
(using the first Futamura projection) turn that code into a compiler. This
would allow a C++ binding generator to map even C++ macro and template
expansion (or literally any other computable C++ language feature) onto a
simple cross-language FFI.

Actually GraalVM already has a powerful partial evaluation framework in
place, but last I checked, even though GraalVM had good C support in place,
there wasn't yet a Truffle IR generator for C++. Have there been
discussions between the Panama team and the Graal team about combining
forces to work on this?

I also saw that Panama dropped direct classfile generation in favor of
generating Java source. Having something like Truffle under the hood is a
much more powerful and flexible IR than either.

(Sorry for the n00b questions... I'm not trying to troll by mentioning
Graal, I am just genuinely interested in finding better ways to build a C++
API generator, and hopefully there are ways to get different related
efforts to work together.)

Luke


More information about the panama-dev mailing list