C++ roadmap

[Maurizio Cimadamore]

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.

If such a capability could be introduced as part of Clang/LLVM, that 
would certainly be a welcome addition; on my part I'm a bit skeptical 
because, it seems to me, this 'lowering' process contains several ad-hoc 
parts (for instance, at some point down the C++ rabbit hole, you realize 
you need a way to say "I want this and that instantiation of this 
template class"), which different frameworks resolve in different ways - 
that is, there's no Right (TM) way to do it, just a bunch of different 
approximations which sort of work.

As for Panama, since Panama is not directly targeting LLVM as a code 
generation backend (at least not in the near future), so, even if such 
support existed I'm not sure we'd be able to immediately take advantage 
of that. There's also the problem of the fact that there are still 
incompatibilities between clang and other native compilers (e.g. MSVC), 
so there can be cases where people might want to generate libraries 
using a very specific platform compiler, in which case we'd have to have 
our own solution (again, at least in the short term).

In any case, I agree with the spirit of your comment, and we would look 
with interest towards any initiative (by LLVM or other tools) which 
helps reducing the semantic gap between C++ and the underlying system ABI.

Maurizio


On 12/08/2019 20:27, Luke Hutchison wrote:
> Thanks for the response, I'm glad your team is working on it, and I'm
> excited to see what can be done. Panama is one of the most interesting
> things to come to the JDK in a long time IMO!
>
> It seems that there are a lot of different languages and LLVM compiler
> frontends that are currently interested in leveraging Clang for automated
> or semi-automated C++ interoperability (Swift and MLIR, as Samuel pointed
> out, as well as Python, Java, and probably others). There are a lot of very
> hard problems to solve when mapping the semantics of C++ onto other
> languages, and some of the solutions to those problems would work for more
> than one language, if mapped through an appropriate abstraction. Would it
> be possible to round up the interested parties to see if it is possible to
> implement some sort of abstraction layer or "Futamura projection" style
> partial evaluator and code generator on top of Clang/LLVM that would
> simplify expressing C++ semantics in a more generic way using just basic
> language features, and that could be shared by all these projects to avoid
> re-inventing the wheel in each case?
>
>
>
>
>
> On Sun, Aug 11, 2019 at 6:52 AM Luke Hutchison <luke.hutch at gmail.com> wrote:
>
>> I tried the most recent Panama JDK 14 build with a C++ header file, and
>> got the following error message (in the form of a RuntimeException):
>>
>> "Unknown type name 'namespace'"
>>
>> I couldn't find a switch in the jextract commandline tool for enabling C++
>> support, so assume this means that C++ is not currently supported. I don't
>> see any mention of the lack of C++ support on the Panama "homepage" or
>> documentation, but I saw a claim somewhere online that Panama only supports
>> C, and has no real immediate plans to support C++. However, discussion in
>> the panama-dev archives seems to indicate that C++ support was always
>> planned.
>>
>> Is there any experimental switch that will enable the use of C++ header
>> files right now in Panama? If not, what is the roadmap for C++?
>>
>>
>>