4 ms·

>The C++ frontend now defaults to C++14 standard instead of C++98 it has been defaulting to previously Honest question, in production, is this sort of a thing

>The C++ frontend now defaults to C++14 standard instead of C++98 it has been defaulting to previously Honest question, in production, is this sort of a thing pretty much a non-issue? Edit: Sorry, to be clearer, I meant to ask, effect of stuff like changing defaults between different versions. Perhaps, it is a non-issue because most production code is (/maybe) version locked. Also, a little vague, but out of curiosity, how often do C / C++ shops upgrade to the latest and greatest?

lmm 10y ago
I don't understand the question. Is there a difference between C++14 and C++98? Yes. Are there important features in C++14 that aren't in C++98? Yes. Is there existing code that builds fine under C++98 and will break when compiled under C++14? Almost certainly yes as well.
- lallysingh 10y ago
  Yes, the differences between C++14 and 98 are night-and-day different. Quite a few important language features, and plenty of new libraries (including threading and lambdas). There aren't any (AFAIK) explicit breaks of '98 code in '14. So the theory is that code should compile with the new compiler fine, but you'll likely hit some issues. Check out Scott Meyers book: Effective Modern C++ for the deltas.
  - MereInterest 10y ago
    There is one break that I know of. `>>` is now parsed as two tokens, and will preferentially mean "close two templates" instead of "right bit shift" in cases of ambiguity.
  - slrz 10y ago
    There are definitely backwards-incompatible changes in the things that were added since C++98. For one, there's a whole set of new keywords that's going to break any code that used them as identifiers. Then there's a keyword that was re-purposed to do something totally different: in C++, auto used to be a storage duration specifier. In C++11 it is used to indicate type inference. There were also changes that, while not breaking source compatibility, basically required implementations to break binary compatibility going from C++98 to C++11. This in particular resulted in a gigantic mess. With regard to breaking changes the C++ committee is not anywhere near as conservative as the one for C.
dnlrn 10y ago
Depends on what kind of production you mean. In your own projects you should set the C++ standard yourself anyway so this is a non-issue. If you are a distribution maintainer, it probably means you have to patch some makefiles that assume that gcc always compiles with c++98
- cm3 10y ago
  This will be fun (not) for distributions. Clang and G++ also seem to be slower when a newer C++ standard is enabled. I don't really buy the argument that changing the default will help new users who want to use C++11 features. Why not make C++14 the default then?
  - Kristine1975 10y ago
    >Why not make C++14 the default then? I might be misunderstanding something, but gcc 6.1 does make C++14 the default.
    - cm3 10y ago
      No, you're right, I misread it.
twoodfin 10y ago
"Non-issue" is probably going a little far, but if you're cutting edge enough in production to be deploying the latest gcc release, you probably have been running with the new frontend already, and ironed out the few deliberate incompatibilities and deprecations in C++11/14 long ago.
bluecalm 10y ago
It's a non-issue in production because you can use the older standard if you want still. It's just a compiler switch.
pjmlp 10y ago
> Also, a little vague, but out of curiosity, how often do C / C++ shops upgrade to the latest and greatest? Very very slow, specially in the enterprise and embedded areas. Back when I used to work in C++, the compilers at my employers were version locked by IT admins, not developers. To make sure all company development projects were in sync. Getting a new compiler version was akin to have a new OS version deployed across the company, from overall process.
unwind 10y ago
I work in embedded software, and I've sometimes felt mildly reactionary for suggesting that yeah, we can use C99. It's not "new". Really! We have "bool" now, for when things are, you know, Boolean! And we can declare variables where we need them, not in a huge prelude in the function ...
- phkahler 10y ago
  more importantly you can - and should - use int16_t and int32_t.
  - Gibbon1 10y ago
    I know they are C99 but I swear I was using stdint or something like it circa 1996
- caf 10y ago
  ITYM "revolutionary" - a "reactionary" is basically the opposite (in a shop that uses C89, a reactionary might advocate for switching back to K&R C).
- caf 10y ago
  More useful than bool and mixed-declarations-and-code, in my opinion, are: designated initialisers; compound literals; inline functions; and varargs macros.

lmm 10y ago

I don't understand the question. Is there a difference between C++14 and C++98? Yes. Are there important features in C++14 that aren't in C++98? Yes. Is there existing code that builds fine under C++98 and will break when compiled under C++14? Almost certainly yes as well.

lallysingh 10y ago
Yes, the differences between C++14 and 98 are night-and-day different. Quite a few important language features, and plenty of new libraries (including threading and lambdas). There aren't any (AFAIK) explicit breaks of '98 code in '14. So the theory is that code should compile with the new compiler fine, but you'll likely hit some issues. Check out Scott Meyers book: Effective Modern C++ for the deltas.
- MereInterest 10y ago
  There is one break that I know of. `>>` is now parsed as two tokens, and will preferentially mean "close two templates" instead of "right bit shift" in cases of ambiguity.
- slrz 10y ago
  There are definitely backwards-incompatible changes in the things that were added since C++98. For one, there's a whole set of new keywords that's going to break any code that used them as identifiers. Then there's a keyword that was re-purposed to do something totally different: in C++, auto used to be a storage duration specifier. In C++11 it is used to indicate type inference. There were also changes that, while not breaking source compatibility, basically required implementations to break binary compatibility going from C++98 to C++11. This in particular resulted in a gigantic mess. With regard to breaking changes the C++ committee is not anywhere near as conservative as the one for C.

dnlrn 10y ago

Depends on what kind of production you mean. In your own projects you should set the C++ standard yourself anyway so this is a non-issue. If you are a distribution maintainer, it probably means you have to patch some makefiles that assume that gcc always compiles with c++98

cm3 10y ago
This will be fun (not) for distributions. Clang and G++ also seem to be slower when a newer C++ standard is enabled. I don't really buy the argument that changing the default will help new users who want to use C++11 features. Why not make C++14 the default then?
- Kristine1975 10y ago
  >Why not make C++14 the default then? I might be misunderstanding something, but gcc 6.1 does make C++14 the default.
  - cm3 10y ago
    No, you're right, I misread it.

twoodfin 10y ago

"Non-issue" is probably going a little far, but if you're cutting edge enough in production to be deploying the latest gcc release, you probably have been running with the new frontend already, and ironed out the few deliberate incompatibilities and deprecations in C++11/14 long ago.

bluecalm 10y ago

It's a non-issue in production because you can use the older standard if you want still. It's just a compiler switch.

pjmlp 10y ago

> Also, a little vague, but out of curiosity, how often do C / C++ shops upgrade to the latest and greatest? Very very slow, specially in the enterprise and embedded areas. Back when I used to work in C++, the compilers at my employers were version locked by IT admins, not developers. To make sure all company development projects were in sync. Getting a new compiler version was akin to have a new OS version deployed across the company, from overall process.

unwind 10y ago

I work in embedded software, and I've sometimes felt mildly reactionary for suggesting that yeah, we can use C99. It's not "new". Really! We have "bool" now, for when things are, you know, Boolean! And we can declare variables where we need them, not in a huge prelude in the function ...

phkahler 10y ago
more importantly you can - and should - use int16_t and int32_t.
- Gibbon1 10y ago
  I know they are C99 but I swear I was using stdint or something like it circa 1996
caf 10y ago
ITYM "revolutionary" - a "reactionary" is basically the opposite (in a shop that uses C89, a reactionary might advocate for switching back to K&R C).
caf 10y ago
More useful than bool and mixed-declarations-and-code, in my opinion, are: designated initialisers; compound literals; inline functions; and varargs macros.