C++ roadmap

[John Rose]

There’s a place-holder for C wrappers on C++ here:

http://cr.openjdk.java.net/~jrose/panama/cppapi.cpp.txt

This is a derived C++ ABI, which is appropriate for “arms length”
separate compilation and invocation.  It doesn’t require any partial
evaluation, though it would (probably) provide a good basis set of
primitive operations for targeting a PE engine or an IR generator
at a C++ API.

The above sketch is also like SWIG, but with all the user knobs withdrawn,
and just the bare C++ operations laid out clearly.

For several reasons we will probably add a way for jextract to emit
C code (or *.o binaries) that include ad hoc wrappers for API points
that do not have corresponding ABI points.  Think C macros and
inlines, and C++ *everything*.  When we figure this out, we can layer
on C++ wrappers as sketched above.

After that we can figure out how to inline those same derived ABI
units.

That’s the way I see it.  One step at a time… 

— John

> On Aug 17, 2019, at 12:20 PM, Luke Hutchison <luke.hutch at gmail.com> wrote:
> 
> 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