JEP draft: Move the JDK to C17 and C++17 | Hacker News Reader

JEP draft: Move the JDK to C17 and C++17

openjdk.org

29 pointsmfiguiere23 comments

Could someone explain what there is to gain from C17? The Wikipedia page just says it fixes defects of C11, but doesn't go into detail.

I've moved projects to C11 for atomics and threads, but never saw a reason to move to C17.

I think the reasoning might be going the other way around : Unless we have a good reason to stay on C11 why not move on to the most recent and compatible language level ?

More recent standards also fixes several issues with C++11 atomics, like the template definition for store/swap conversions were mis-specified, so they did not work, and atomics were not defined to be compatible with C11 and now are going to be. So there are further usability improvements that come with the later standards, beyond the initial standardization that C11 brought to the table. It is not like you had needed C11 to get threads either before, but it does make the code clearer and more portable now.

I think the HN title is incorrect, the title in the linked post just says C++17, not C17. Likewise, the JEP doesn't really mention C other than in passing, and the OpenJDK code I've looked at myself is all written in C++, so AFAIK this is really just a change from C++14 to C++17.

As for the differences between C++14 and C++17, the things I use most often are consexpr if, variable declaration in if statements, std library features like std::optional and std::string_view, lambdas got more powerful, and probably a bunch of other things I'm forgetting. There are a ton of "What's new in C++17" articles you can find online if you want more information.

The title of the draft JEP was "Move the JDK to C17 and C++17" at the time of posting but has been changed later to "Compile the JDK as C++17". Not able to edit the HN post anymore.

You can email hn@ycombinator.com and they'll fix it.

There's a weird tendency to lump together C and C++ into "C/C++", as though it was the same language. Makes about as much sense as Java/Javascript at this point.

There's a weird tendency to lump together C and C++ into "C/C++", as though it was the same language.

It’s about as weird as writing “HTML/CSS/JS”, or “Java/Kotlin”. Like it or not people write related languages and technologies that way.

Makes about as much sense as Java/Javascript at this point.

Do you know what “ISO/IEC JTC1/SC22/WG21/SG22” is? It’s the C and C++ Compatibility Study Group for ISO C++. For instance the only reason C++20 added designated initializers was for improving C compatibility.

Stop pretending C and C++ have nothing to do with each other. Using “C/C++” is fine.

> For instance the only reason C++20 added designated initializers was for improving C compatibility.

That would be true if you ignore the fact that designated initializers are superb syntactic sugar that greatly contributes to fewer bugs and better readability.

C++ has constructors, designated initializers are redundant.

std::optional is so great. No more magic return values! Forces people to consider whether something will exist than just writing for the best case.

In this case it might just be standard procedure to move to "language_standard = current_year - N" without any specific code base changes in mind. It makes sense to not fall behind too much (to not allow surprises to pile up, even if no code changes are planned), while also not using the latest standard which might still have incomplete compiler support.

In the compiler I'm working on, the only differences between selecting C11 and C17 modes are: * the value of __STDC_VERSION__ * DR423 (https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_423.htm) * DR481 (https://www.open-std.org/Jtc1/sc22/wg14/www/docs/n2001.pdf)

Note that many compilers backport defect reports to older language versions (i.e. they unconditionally adopt the new behavior independent of the -std= switch). The changes above can change the meaning of existing valid programs, so we're a bit more careful there. However I believe gcc+clang both have always used the new post-DR481 behavior for _Generic (essentially, a gcc+clang bug was resolved by changing the language standard in C17, because the gcc+clang behavior makes more sense than the C11 specified behavior).

Heya, I'm the guy who posted that JEP, since I felt like Oracle has talked about moving to C++17 long enough without acting on it. Very honoured to be part of a Hacker News thread! :P

Good news, C++17 is already quite productive.

By the way there is nothing about C on the JEP.

"quite productive"? If I'm not wrong, all the major compilers have full C++17 support and almost complete C++20. And C++23 is coming.

You're quite wrong.

https://en.cppreference.com/w/cpp/compiler_support

VC++ is the only one with good enough C++20 support, and even it, it isn't without issues.

So C++17 is the best one can get for portable code, and compared with traditional C derived languages versus other high level languages, quite productive.

I've removed all references to C in the JEP, after others advised me to do so. I did initially create the JEP as "Move the JDK to C17 and C++17"

Is c++20 which is 3 years old not portable enough?

Not at all, specially when talking about clang.

gcc's c++20 support is still considered "experimental", which means libstdc++ does not guarantee ABI stability when using c++20. The JDK is compiled and distributed by various entities using various styles of linking. The lack of ABI stability might be problematic for some of them.

Won’t any such things require inclusion of experimental headers?

I've proposed this in the past, but the AIX port does not yet have an available compiler that compiles working C++20. Maybe sometime in the future!

Reply on news.ycombinator.com