10 ms·

GCC: Patch to change default C++ dialect to C++14

129 points by nly 11y ago

cosarara97 11y ago
Won't this break stuff?
- nadams 11y ago
  That's probably the reason why C++11 wasn't ever the default. Though, there are arguments about trying to be backwards compatible forever. My personal opinion is to leave it the way it is - or at the very least default to C++11 first.
  - plorkyeran 11y ago
    C++14 didn't introduce any new breaking changes to pre-C++11 functionality, so switching to C++11 first would not make the migration now any easier and would introduce the need for another migration in the future.
- nly 11y ago
  It shouldn't. 99.5% of C++98 code is valid C++14. Code compiled as C++98 and code compiled as C++14, should also link.
  - AnimalMuppet 11y ago
    So if my code is at least 200 lines long... (I know, it doesn't work like that. 99.5% means syntax elements or some such, not lines of code. But it still works out the same in a medium-to-large code base; 99.5% compatibility breaks more than you expect.)
  - ridiculous_fish 11y ago
    I maintain a project that compiles as both C++11 and C++03. One pain point is that the headers have changed between them: #include <tr1/memory> to #include <memory>. This is complicated further by libc++, which doesn't have <tr1/memory>.
    - rleigh 11y ago
      That's fairly straightforward to work around, however. I've used both autoconf and cmake to do functional testing of which headers are available, and then include the most recent available out of <memory>, <tr1/memory> and <boost/shared_ptr.hpp>, bringing them into a project::compat namespace to make the codebase not need to care which is in use, and the same for a number of other tr1/boost types now in C++11/14. I'm now at the point where for some projects I've been able to strip out this entirely and just use the C++11 types directly.
      - gurkendoktor 11y ago
        That is relatively straightforward in the scope of a large project (and it's what I do as well), but stuff like this really makes it harder to share small-to-medium sized C++ libraries. I don't understand why C++03 didn't just use the std:: namespace.
    - Sanddancer 11y ago
      What about a preprocessor check based on the __cplusplus value? If it's 199711L, implement the C++03 defines, if not, implement the C++11 defines.
      - gurkendoktor 11y ago
        A quick Google search suggests that this won't work unless you also check for the MSVC version - sigh: http://stackoverflow.com/questions/14131454/visual-studio-2012-cplusplus-and-c-11 http://stackoverflow.com/questions/14131454/visual-studio-20...
        StephanTLavavej 11y ago
        If we changed __cplusplus before implementing every single C++11 feature, the Internet would riot.
        lmm 11y ago
- cremno 11y ago
  Maybe. For example, GCC 5 changed the default for C from gnu89 to gnu11 and that broke the build of some Finnish amateur project: https://lkml.org/lkml/2014/10/19/94 https://lkml.org/lkml/2014/10/19/94 That's why projects that use GCC or a compatible compiler should use the -std option to set the targeted standard and not rely on the default.
  - ajross 11y ago
    Pretty much. Taking the "will this break stuff?" worry to the logical extreme would mean that gcc should default to a pre-standarization K&R dialect and g++ to a cfront dialect contemporary with 1st edition Stroustrup. The world moves on. Though if you're an active project, moving along with the world is probably a better option than throwing in --std=c++really-old and deliberately refusing to use new stuff.
  - rbanffy 11y ago
    Forcing the update of old code doesn't make me sad. Considering new versions of the language should be improvements over previous ones, it may be a good side effect. If your code breaks with the new compiler and language standard, just change your build options to explicitly use the previous one.
- koenigdavidmj 11y ago
  If you maintain one of the rare codebases that would break, then just add "--std=c++98" to your compiler flags. GCC has already been getting steadily more strict by default, or at least opt-in with -Wall -Werror. The last time we updated our build environment, we had to go in and #include all the headers that were formerly implicit (or #include-d by other headers), and add in the 'const' every time we referred to a string literal. The possibly-unassigned variable checker also got a lot more sophisticated and now would enter called functions.
  - GFK_of_xmaspast 11y ago
    I've been lead to believe that gcc can't / won't add warnings to -Wall precisely because of all the codebases that have -Werror.
    - cpeterso 11y ago
      New versions of gcc routinely fail to compile Firefox out of the box. A good example was gcc 4.7's -Wunused-local-typedefs, which is part of -Wall. Local typedefs seem to be a common pattern in Firefox's generated C++ (for IDL bindings).
      - andrewchambers 11y ago
        This is why I think static bug checking and compiling should be two different tools. There is no reason to fail a build which used to run, even if it has bugs. Doing all those checks at build time is slowing the build down too.
        deleted 11y ago
        [deleted]
        plorkyeran 11y ago
        Splitting static checks and compiling into separate tools will not prevent your builds from breaking when you update your tools if you have your build process deliberately configured to break whenever a new warning appears. GCC adding new warnings will not break your builds if you do not specifically ask for it to by using -Werror (or having your CI system reject any builds that produce warnings). At least with clang, -Weverything is not measurably slower than no warnings at all on any vaguely realistic code base.
- plq 11y ago
  Actually, I'm more interested in when a GCC with this patch will be marked stable by one of the distros that I use.
santaclaus 11y ago
How long before this happens on Clang?
- BudVVeezer 11y ago
  It's something we're discussing and exploring. The general thought is that Clang could do this for everything but sized deallocations (and it's unclear how much of an issue those would pose).
  - scotty79 11y ago
    C++14 is awesome language, I didn't have much contact with C++ development for over a decade but I keep one eye on how C++ develops and am amazed of how flexible things became without abandoning strictness altogether C# "dynamic" kind of way. Keeping strictness in the language allows for awesome tooling so I tried yesterday to find good IDE for C++14. There's not much on the market. Clion is decent but doesn't handle code completion for auto return type. Clang does, so Atom code editor with clang based auto-complete plugin works better than Clion. But I have luck for finding issues in the things I touch so I immediately encountered something that's not supported by clang autocomplete. It turned out of course that I'm not the first one to encounter this issue: https://llvm.org/bugs/show_bug.cgi?id=14446 https://llvm.org/bugs/show_bug.cgi?id=14446 Since it's hanging there since 2012 I understand it's a low priority issue. Could you give me any pointers of how could I help with implementing this feature? Maybe point me to files that I'd need to alter to attempt to implement this?
deleted 11y ago
[deleted]
Someone1234 11y ago
This might be a terrible idea, but maybe it is a good time to scrap the concept of a default completely. Wouldn't it be more future proof just to FORCE everyone to have to specify which language version they're targeting? That way when a new one is added it has absolutely no impact on the historical ones. It isn't like c++14 is going to be the last version ever. PS - If GCC is still in use in 2098 then things may get awkward.
- frozenport 11y ago
  >>just to FORCE everyone to have to specify which language version they're targeting? There is a thought. I see a lot of trouble from this proposal because the compilers and supplied libraries have a history of including extra things. Until quiet recently C++ headers would drop in C that nobody asked for. Personally, I was surprised to find that on Windows I could throw std::runtime_error. At the end of the day a lot of code would break, because nobody is sure exactly what standard they are actually are using.
  - kbenson 11y ago
    Is there a technical reason that would prevent the compiler from honoring a per-file pragma that allowed the developer to define how the code was expected to be interpreted by the compiler?
    - eru 11y ago
      Haskell's GHC is doing exactly that. You can even mix and match pragmas for different extensions.
      - kbenson 11y ago
        I know Perl has done the same for quite a while now.
      - Argorak 11y ago
        I find it terribly confusing. It means that Haskell is almost never something I can expect a lot from, but a weird combination of extensions changing to "non-standard" behaviours.
ndesaulniers 11y ago
OH: "Now for updating the default C std"

129 points by nly 11y ago

cosarara97 11y ago

Won't this break stuff?

nadams 11y ago
That's probably the reason why C++11 wasn't ever the default. Though, there are arguments about trying to be backwards compatible forever. My personal opinion is to leave it the way it is - or at the very least default to C++11 first.
- plorkyeran 11y ago
  C++14 didn't introduce any new breaking changes to pre-C++11 functionality, so switching to C++11 first would not make the migration now any easier and would introduce the need for another migration in the future.
nly 11y ago
It shouldn't. 99.5% of C++98 code is valid C++14. Code compiled as C++98 and code compiled as C++14, should also link.
- AnimalMuppet 11y ago
  So if my code is at least 200 lines long... (I know, it doesn't work like that. 99.5% means syntax elements or some such, not lines of code. But it still works out the same in a medium-to-large code base; 99.5% compatibility breaks more than you expect.)
- ridiculous_fish 11y ago
  I maintain a project that compiles as both C++11 and C++03. One pain point is that the headers have changed between them: #include <tr1/memory> to #include <memory>. This is complicated further by libc++, which doesn't have <tr1/memory>.
  - rleigh 11y ago
    That's fairly straightforward to work around, however. I've used both autoconf and cmake to do functional testing of which headers are available, and then include the most recent available out of <memory>, <tr1/memory> and <boost/shared_ptr.hpp>, bringing them into a project::compat namespace to make the codebase not need to care which is in use, and the same for a number of other tr1/boost types now in C++11/14. I'm now at the point where for some projects I've been able to strip out this entirely and just use the C++11 types directly.
    - gurkendoktor 11y ago
      That is relatively straightforward in the scope of a large project (and it's what I do as well), but stuff like this really makes it harder to share small-to-medium sized C++ libraries. I don't understand why C++03 didn't just use the std:: namespace.
  - Sanddancer 11y ago
    What about a preprocessor check based on the __cplusplus value? If it's 199711L, implement the C++03 defines, if not, implement the C++11 defines.
    - gurkendoktor 11y ago
      A quick Google search suggests that this won't work unless you also check for the MSVC version - sigh: http://stackoverflow.com/questions/14131454/visual-studio-2012-cplusplus-and-c-11 http://stackoverflow.com/questions/14131454/visual-studio-20...
      - StephanTLavavej 11y ago
        If we changed __cplusplus before implementing every single C++11 feature, the Internet would riot.
        lmm 11y ago
cremno 11y ago
Maybe. For example, GCC 5 changed the default for C from gnu89 to gnu11 and that broke the build of some Finnish amateur project: https://lkml.org/lkml/2014/10/19/94 https://lkml.org/lkml/2014/10/19/94 That's why projects that use GCC or a compatible compiler should use the -std option to set the targeted standard and not rely on the default.
- ajross 11y ago
  Pretty much. Taking the "will this break stuff?" worry to the logical extreme would mean that gcc should default to a pre-standarization K&R dialect and g++ to a cfront dialect contemporary with 1st edition Stroustrup. The world moves on. Though if you're an active project, moving along with the world is probably a better option than throwing in --std=c++really-old and deliberately refusing to use new stuff.
- rbanffy 11y ago
  Forcing the update of old code doesn't make me sad. Considering new versions of the language should be improvements over previous ones, it may be a good side effect. If your code breaks with the new compiler and language standard, just change your build options to explicitly use the previous one.
koenigdavidmj 11y ago
If you maintain one of the rare codebases that would break, then just add "--std=c++98" to your compiler flags. GCC has already been getting steadily more strict by default, or at least opt-in with -Wall -Werror. The last time we updated our build environment, we had to go in and #include all the headers that were formerly implicit (or #include-d by other headers), and add in the 'const' every time we referred to a string literal. The possibly-unassigned variable checker also got a lot more sophisticated and now would enter called functions.
- GFK_of_xmaspast 11y ago
  I've been lead to believe that gcc can't / won't add warnings to -Wall precisely because of all the codebases that have -Werror.
  - cpeterso 11y ago
    New versions of gcc routinely fail to compile Firefox out of the box. A good example was gcc 4.7's -Wunused-local-typedefs, which is part of -Wall. Local typedefs seem to be a common pattern in Firefox's generated C++ (for IDL bindings).
    - andrewchambers 11y ago
      This is why I think static bug checking and compiling should be two different tools. There is no reason to fail a build which used to run, even if it has bugs. Doing all those checks at build time is slowing the build down too.
      - deleted 11y ago
        [deleted]
      - plorkyeran 11y ago
        Splitting static checks and compiling into separate tools will not prevent your builds from breaking when you update your tools if you have your build process deliberately configured to break whenever a new warning appears. GCC adding new warnings will not break your builds if you do not specifically ask for it to by using -Werror (or having your CI system reject any builds that produce warnings). At least with clang, -Weverything is not measurably slower than no warnings at all on any vaguely realistic code base.
plq 11y ago
Actually, I'm more interested in when a GCC with this patch will be marked stable by one of the distros that I use.

santaclaus 11y ago

How long before this happens on Clang?

BudVVeezer 11y ago
It's something we're discussing and exploring. The general thought is that Clang could do this for everything but sized deallocations (and it's unclear how much of an issue those would pose).
- scotty79 11y ago
  C++14 is awesome language, I didn't have much contact with C++ development for over a decade but I keep one eye on how C++ develops and am amazed of how flexible things became without abandoning strictness altogether C# "dynamic" kind of way. Keeping strictness in the language allows for awesome tooling so I tried yesterday to find good IDE for C++14. There's not much on the market. Clion is decent but doesn't handle code completion for auto return type. Clang does, so Atom code editor with clang based auto-complete plugin works better than Clion. But I have luck for finding issues in the things I touch so I immediately encountered something that's not supported by clang autocomplete. It turned out of course that I'm not the first one to encounter this issue: https://llvm.org/bugs/show_bug.cgi?id=14446 https://llvm.org/bugs/show_bug.cgi?id=14446 Since it's hanging there since 2012 I understand it's a low priority issue. Could you give me any pointers of how could I help with implementing this feature? Maybe point me to files that I'd need to alter to attempt to implement this?

deleted 11y ago

[deleted]

Someone1234 11y ago

This might be a terrible idea, but maybe it is a good time to scrap the concept of a default completely. Wouldn't it be more future proof just to FORCE everyone to have to specify which language version they're targeting? That way when a new one is added it has absolutely no impact on the historical ones. It isn't like c++14 is going to be the last version ever. PS - If GCC is still in use in 2098 then things may get awkward.

frozenport 11y ago
>>just to FORCE everyone to have to specify which language version they're targeting? There is a thought. I see a lot of trouble from this proposal because the compilers and supplied libraries have a history of including extra things. Until quiet recently C++ headers would drop in C that nobody asked for. Personally, I was surprised to find that on Windows I could throw std::runtime_error. At the end of the day a lot of code would break, because nobody is sure exactly what standard they are actually are using.
- kbenson 11y ago
  Is there a technical reason that would prevent the compiler from honoring a per-file pragma that allowed the developer to define how the code was expected to be interpreted by the compiler?
  - eru 11y ago
    Haskell's GHC is doing exactly that. You can even mix and match pragmas for different extensions.
    - kbenson 11y ago
      I know Perl has done the same for quite a while now.
    - Argorak 11y ago
      I find it terribly confusing. It means that Haskell is almost never something I can expect a lot from, but a weird combination of extensions changing to "non-standard" behaviours.

ndesaulniers 11y ago

OH: "Now for updating the default C std"