4 ms·

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

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.

soulbadguy 3y ago
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 ?
- manwe150 3y ago
  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.
eklitzke 3y ago
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.
- mfiguiere 3y ago
  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.
  - tjalfi 3y ago
    You can email hn@ycombinator.com and they'll fix it.
- marginalia_nu 3y ago
  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.
  - SubjectToChange 3y ago
    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.
    - 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 ago
        C++ has constructors, designated initializers are redundant.
- Night_Thastus 3y ago
  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.
flohofwoe 3y ago
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.
ynik 3y ago
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 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).

soulbadguy 3y ago

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 ?

manwe150 3y ago
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.

eklitzke 3y ago

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.

mfiguiere 3y ago
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.
- tjalfi 3y ago
  You can email hn@ycombinator.com and they'll fix it.
marginalia_nu 3y ago
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.
- SubjectToChange 3y ago
  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.
  - 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 ago
      C++ has constructors, designated initializers are redundant.
Night_Thastus 3y ago
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.

flohofwoe 3y ago

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.

ynik 3y ago

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 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).