C++ roadmap

[Samuel Audet]

Hi, Maurizio,

It's good to hear that you're actually starting to think about the real 
problems. I'm looking forward to see how "soon" you'll be able to come 
to conclusions that I believe will be very similar to mine, which I've 
been writing about on this forum for over 5 years now. I consider those 
messages a "contribution". Agreed, I should try to find a way to say 
this less sarcastically, I'm sorry about that, but you're right, I am 
after all frustrated.

Anyway, I don't remember if I've mentioned this before, but Visual 
Studio now officially supports Clang as a C++ compiler "out of the box". 
In my opinion, it is likely that as soon as this page:
     https://clang.llvm.org/docs/MSVCCompatibility.html
Starts to look like this one:
     https://clang.llvm.org/compatibility.html
Microsoft will drop MSVC, simply because there are so many more 
developers working on Clang/LLVM when compared to MSVC, or GCC for that 
matter (whose support was dropped from Mac/iOS and Android). If that 
ever happens, LLVM will have become the defacto C++ runtime, and trying 
to support anything else might very well become pointless, since any 
competition to LLVM will have to follow them.

Now, after many many exchanges on this mailing list, it was made at last 
clear that OpenJDK has no intention of using LLVM. It would have saved 
me and others a lot of trouble to have made this clear from the start.

Others like Luke and Cyprien do understand the importance of this, so if 
Microsoft does end up adopting LLVM across the board, and OpenJDK still 
doesn't get it, I hope the industry will be able to move the leadership 
of Java away from OpenJDK... but we're not quite there yet.

Samuel

On 8/13/19 5:35 AM, Maurizio Cimadamore 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.
> 
> 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++?
>>>
>>>