4 ms·
JEP draft: Move the JDK to C17 and C++17
- tristan957 3y agoCould 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.
- soulbadguy 3y agoI 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 ?
- manwe150 3y agoMore 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.
- eklitzke 3y agoI 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.
- mfiguiere 3y agoThe 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.
- tjalfi 3y agoYou can email hn@ycombinator.com and they'll fix it.
- marginalia_nu 3y agoThere'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.
- SubjectToChange 3y agoThere'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.
- rewmie 3y ago> 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.
- SubjectToChange 3y agoC++ has constructors, designated initializers are redundant.
- flohofwoe 3y agoIn 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.
- ynik 3y agoIn 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 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 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).
- vlovich123 3y agoIs c++20 which is 3 years old not portable enough?
- pjmlp 3y agoNot at all, specially when talking about clang.
- ynik 3y agogcc'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.
- vlovich123 3y agoWon’t any such things require inclusion of experimental headers?
- _vertig0 3y agoI'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!
- pjmlp 3y agoGood news, C++17 is already quite productive. By the way there is nothing about C on the JEP.
- madduci 3y ago"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.
- pjmlp 3y agoYou're quite wrong. https://en.cppreference.com/w/cpp/compiler_support 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.
- _vertig0 3y agoI'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"
- _vertig0 3y agoHeya, 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