10 ms·

In commercial settings, I encounter several barriers to using C++ versions newer than 2011: (1) Most C++ code I encounter is C++11, and I deal with lots of pro

In commercial settings, I encounter several barriers to using C++ versions newer than 2011: (1) Most C++ code I encounter is C++11, and I deal with lots of projects. It's rarely sensible to change the language version of a large code base without a very good reason. (2) Many developers are well-familiar with C++11. (3) There's no widespread perception that C++14 or later bring compelling language improvements. (4) Some (most?) C++11 developers are already uneasy with the complexity of C++11, and aren't eager to incur the learning curve and (perhaps) new set of pitfalls associated with newer C++ versions. (5) Some C++11 developers look at the language trajectory, especially in terms of complexity, and have decided that their next language(s) will be e.g. Rust or Julia instead of C++14, C++17, etc. I suspect these factors all contribute to the momentum that C++11 seems to have.

w-m 7y ago
On the other hand, there aren't really any changes in 14 and 17 that break compatibility with code written in 11, at least that I'm aware of. In the examples I've seen it seems to mostly come down to compiler, toolchain and 3rd party binary availability for the new versions, like with any major language version. If for example you are using stock gcc from Ubuntu 16.04 for your builds, you can't use C++17.
- Fronzie 7y ago
  For big (legacy) code-bases, just upgrading the compiler is a project by itself. All 3rd party C++ libs need to be upgraded, all internal projects need to upgrade in an orderly fashion. On top of that, just the change of the compiler will expose some pre-existing bugs.The bugs might have been there, but are not a problem for the business if they currently don't show. I've seen projects with a core team of half a dozen people, supported by the other SW engineers working for 6 months just to upgrade to a newer version of windows and the compiler. This was mostly due to unwise SW-design decisions accumulated over 15+ years.
  - w-m 7y ago
    I totally agree, updating compilers is painful, and can be hard even for smaller projects. But for projects that went through that and actually got the newer compiler working with the C++11 code, I haven't yet seen anything that breaks compilation when then switching the compiler flag to C++14 mode.
  - jandrewrogers 7y ago
    You raise a good point about newer compilers doing much deeper analysis of the code than older compilers. I have experienced the horror of compiling an old, nominally clean C++11 code base with the latest version of clang++ and seeing a small avalanche of errors and warnings that weren't picked up by the compiler when that code was written. It creates a lot of work, and frequently the nature of the bugs are not material (i.e. in context they may not produce a runtime fault), but I do find it to be good hygiene. I used to do builds with two different compilers for the same purpose, though that found compiler bugs as often as it found issues in the code.
  - d1zzy 7y ago
    Plus, a lot of new library and language features are simply standardized versions of features that mature codebases had their own solutions for years, so "upgrading" to a newer C++ may also imply a long process of deprecating these alternatives in favor of standard ones, and the subtle differences between the two can expose new bugs and issues.
  - cpeterso 7y ago
    Here is a list of some real-world examples of bugs that Mozilla had to fix when upgrading from Firefox from C++11 to C++14 to C++17 (still in progress). Many of these are compiler issues from upgrading to clang or gcc versions recent enough to support the new C++ versions, not C++ language changes. https://bugzilla.mozilla.org/showdependencytree.cgi?id=1560664&hide_resolved=0 https://bugzilla.mozilla.org/showdependencytree.cgi?id=15606...
    - dgellow 7y ago
      Your link requires to be logged in to see the actual bug ticket.
- gumby 7y ago
  > On the other hand, there aren't really any changes in 14 and 17 that break compatibility with code written in 11, at least that I'm aware of. auto_ptr has thankfully be removed, but if you have legacy code that uses it it won't compile under C++17. Of course if you have code that uses auto_ptr you should fix it, but realistically nobody has the time for that.
  - ludamad 7y ago
    I mean, if tricky usage of auto_ptr is stopping you, you could probably use a drop-in replacement. But the 'and this adds to the sprint tasks how?' question still isn't answered in a good way
    - TillE 7y ago
      You could probably just find/replace unique_ptr. I'm pretty sure that's what I did a million years ago when auto_ptr was deprecated. C++17 does break some code by removing a few things, but they're pretty trivial and nothing sneaky.
      - tjalfi 7y ago
        clang-tidy has a command to replace auto_ptr with unique_ptr[0]. I haven't used it in anger, though. [0] https://clang.llvm.org/extra/clang-tidy/checks/modernize-replace-auto-ptr.html https://clang.llvm.org/extra/clang-tidy/checks/modernize-rep...
  - MauranKilom 7y ago
    Depends on how much it was used. But I was part of the effort to convert to C++17 for our (substantial) C++ code base of ~30 years and it was not painful at all.
  - twoodfin 7y ago
    I also ran up against the deprecation of std::mem_fun and std::mem_fun_ref in a recent migration. Easy enough to replace with lambda expressions, but one more hurdle to running C++17 code.
jcranmer 7y ago
> (3) There's no widespread perception that C++14 or later bring compelling language improvements. Constexpr if (introduced in C++17). If you're building a library that uses templated types (and therefore static dispatch instead of virtual functions and dynamic dispatch), then using constexpr if dramatically simplifies the implementation of your code.
- saghm 7y ago
  I don't think GP was arguing that there weren't any compelling language improvements, just that there isn't a "widespread perception" of those improvements.
CreRecombinase 7y ago
C++11 vs C++14/C++17/C++20 is not python2 vs python3. Because of the emphasis on backwards compatibility, you can often just recompile your C++11 project with the new version of the standard and everything should just work. Backwards compatability also means that the newer versions are only as "complex" as the features you choose to use.
- saghm 7y ago
  The tricky part of this is that if your project is a library, you're not just opting into having to update your own toolchain, but also that of all your users. This means that a lot of library developers will err on the side of not updating their minimum version, which in turn means application developers don't have as much pressure to update either. This isn't specific to C++ by any means, but I think it does pop up a bit more in this space due to the fact that a lot of developers prefer to just use the default toolchain of their system, so forcing downstream users to update their toolchain could be viewed as a bit more of a maintenance burden.
htns 7y ago
Re (5), I rather feel that the quality of the documentation and communication around modern C++ puts everything else to shame. If you knew java or python in 2009, how are you supposed to quickly catch up with 2019? (Rust also seems to have piled on a lot of additions since 1.0, but I don't use it so I shouldn't speak.) There are books and blogs for everything popular, but it's really a little shocking to me that no other big language has anything that can compare to cppreference.com. This doesn't change what people other than me might be thinking, of course.
- dgellow 7y ago
  I guess it's a question of habit. I'm learning C++ during my free time since a few months. I find cppreference.com really difficult to parse. I understand way more of the documentation now than when I started because of the bit of experience I gained, but it is written in a way that makes everything sounds really over-complicated. I remember when I googled for something and arrived at the page about "Value category": https://en.cppreference.com/w/cpp/language/value_category https://en.cppreference.com/w/cpp/language/value_category. If you're not already well familiar with the language, this page is really hard to understand IMHO. I found it way easier to deal with Go, C#, and Ruby documentation for example.
  - gpderetta 7y ago
    Cppreference is great, but it is not the best place to learn the language.
  - east2west 7y ago
    I don't recommend cppreference for novices. It is by no means an easy read. It is a reference, first of all. It enumerates all possible minutiae exhaustively. Unless you are already familiar, to a degree, with most of the topics, reading it is going to be frustrating. The second obstacle is the terminology. C++ defines a lot of terms that are not in common use in other languages. It takes time to be acclimated. The reason that it is popular in the C++ community is that it cuts down legalese a lot when compared to the language standard. Try books first. Meyers and Josuttis write excellent books. The template guide by Vandevoorde and Josuttis is my gateway drug to becoming a language lawyer. It is still hard, but at least manageable.
CoolGuySteve 7y ago
ABI stability of the STL is the biggest issue I've seen. Upgrading from C++11 to C++17 becomes a bust if any of your 3rd party libraries want to pass even a basic std::string. I don't know what the hold up is on modules. Even a basic "this header uses a C++11 namespace" functionality would fix most of the problems. But even better would be something like "extern 'Cwrapper'" that would let you expose C++ objects as a C API with a void* object pointer without having to do the pointless wrapper dance every time. Like make the compiler convert "class Thing { doThing(int a); }" to "typedef void* Thing; Thing_doThing(Thing* this, int a);" automatically so that other languages can call me.
- Ididntdothis 7y ago
  I don’t understand why they don’t do more about ABI. Compared to C# or java it’s such a pain to share code in C++. To me this would open up a lot of opportunities to create more libraries.
  - gpderetta 7y ago
    They do. ABI breaking changes are routinely voted down unless they are really worth it (and the only non backward compatible change that was accepted that I'm aware is the std string changes in C++11).
    - Ididntdothis 7y ago
      Maybe things are better now but in the past almost every new library I added to my projects required a lot of fiddling with headers , link options and other stuff. With C# this is so easy in comparison.
    - steveklabnik 7y ago
      This paper is related and interesting: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1863r0.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p186...
      - 7y ago
dgellow 7y ago
Do you think that will change with introduction of modules? Would that be a feature compeling enough to make people move to newer versions of the standard?
jandrewrogers 7y ago
I don't encounter these barriers in commercial settings. The biggest barrier is compiler support if you target environments with different compiler toolchains. Each new version of C++ brings features and bug fixes that make code simpler. It actually reduces complexity from the perspective of the developer. The forcing function for upgrading C++ versions in my teams is always that it would greatly simplify some immediate problem or allow us to remove a gross (but necessary) hack due to the limitations of prior versions. At least with the LLVM toolchain, upgrades have been nearly issue-free so there is little to recommend not doing it. C++17 is a big upgrade over C++11 functionally. Developers that do not see compelling improvements probably weren't using most of the functionality of C++11 anyway. While the number of features and quirks in standard C++ grows with each version, the subset that a developer needs to remember to write correct idiomatic code is shrinking with each new version as capabilities become more general and the expression of those capabilities simpler. There is a new, simpler, and vastly more capable language evolving out of the old one and you can increasingly live almost entirely within this new language as a developer. I hated classic C++ but I actually really like this new C++, and it allows me to write far less code for the same or better result. There are still many things that C++ can express simply and efficiently that Rust, Julia, etc cannot. If you work on software that can take advantage of that expressiveness (e.g. databases in my case), the cost of changing languages is quite large.
- dgellow 7y ago
  > There is a new, simpler, and vastly more capable language evolving out of the old one and you can increasingly live almost entirely within this new language as a developer. How is that true in practice? I would expect that once you have a codebase big enough, instead of living only with the new language you still have to deal with (or at least read) code written in previous versions of the language. And so instead of having to know only the modern subset you would have to keep in mind all the potential quirks from previous versions.
  - jandrewrogers 7y ago
    Sure, you will have code written in an older idiomatic style but there is some continuity, most C++17 programmers used to be C++11/14 programmers. Upgrading code from e.g. C++11 to C++17 is relatively incremental, typically easily recognized, and can be done opportunistically. Obviously going from C++03 to C++17 would be much more expensive, so that is a bit of a different case. Rapid improvements in code analysis often breaks previously clean builds in newer compilers, so you often find yourself doing hygienic work on old C++ code anyway. This does imply some ongoing maintenance work related solely to keeping the code base consistently "modern". This almost always makes the C++ simpler and more maintainable and often reduces the line count, so it is worth the nominal investment. The massive improvement in template code readability is worth the price of admission all by itself.
microtherion 7y ago
> There's no widespread perception that C++14 or later bring compelling language improvements. I would argue the opposite: C++11 is a fairly different paradigm to C++03, and upgrading an existing code base is a sizable project. But once you get hooked into the concepts it introduces (auto, lambdas, templates, constexpr), each subsequent revision of the language standard introduces some improvement to these concepts that deals with unpleasant edge cases the earlier revision had, so each of them promises to make your existing use cases simpler, at a moderate rewrite expense.
einpoklum 7y ago
(1) It's actually rather sensible, because C++ is famous for its backwards compatibility. So you can use C++14 or C++17 features in some new code while leaving the rest as-is - and gradually refactoring some of it with new features. (2) This used to be the case with C++03 (or C++98), and it changed... (3) I partially disagree and partially claim you're begging the question. You don't have poll results to suggest what people think of C++14. But - C++14 had a lot less changes compared to C++11 or C++17; this was natural considering how the cycle of debate of potential features progressed. The thing is, the fact that C++14 wasn't that revolutionary in terms of features also means it is easier to adopt. If you want more novelty - try C++17; or - try a C++14-dependent library like Eric Niebler's ranges-v3. (4) C++17 allows for writing less complex code in many cases. Specifically, you can significantly reduce the need for template metaprogramming - a particularly hairy part of the language - by using more constexpr functions and if-constexpr in regular functions. And there are other examples. Like Bjarne says: The C++ committee endeavors to "make simple things simple (to write)". So it's a trade-off. (5) Some people switch languages because of workplace decisions or personal preferences, that's true; but people also adopt C++ because of what becomes possible, or easily-expressible, with newer versions of the language. For example, using the ranges library and with C++14 or later, functional programming with C++ has become quite reasonable, borderline pleasant even. --- Bottom line: In my opinion, at this point C++11 has more inertia than momentum. And that's ok. People will progress over time.
- nestorD 7y ago
  (4) is my main reason for missing C++17 when I am on a project stuck with C++11. I feel that the template metaprogramming framework deserves an overhaul to clean up historical mistakes and keep only the good part.
  - einpoklum 7y ago
    In C++ there are almost never any overhauls - it's almost always new functionality that can replace older functionality. That's what compile-time evaluation is to template metaprogramming.
- pacman128 7y ago
zelly 7y ago
They will switch to 20 for modules. No. 1 headache is build times. It will literally save money.
paulddraper 7y ago
> here's no widespread perception that C++14 or later bring compelling language improvements. C++14 didn't add a whole lot of new things; it mostly improved on existing features. C++17 adds a number of new things. I would use it just for std::optional and std::variant though.
SamReidHughes 7y ago
C++14’s compelling improvement is initialization in capture lists, so you don’t have to copy into them. I haven’t seen anything compelling beyond that.

w-m 7y ago

On the other hand, there aren't really any changes in 14 and 17 that break compatibility with code written in 11, at least that I'm aware of. In the examples I've seen it seems to mostly come down to compiler, toolchain and 3rd party binary availability for the new versions, like with any major language version. If for example you are using stock gcc from Ubuntu 16.04 for your builds, you can't use C++17.

Fronzie 7y ago
For big (legacy) code-bases, just upgrading the compiler is a project by itself. All 3rd party C++ libs need to be upgraded, all internal projects need to upgrade in an orderly fashion. On top of that, just the change of the compiler will expose some pre-existing bugs.The bugs might have been there, but are not a problem for the business if they currently don't show. I've seen projects with a core team of half a dozen people, supported by the other SW engineers working for 6 months just to upgrade to a newer version of windows and the compiler. This was mostly due to unwise SW-design decisions accumulated over 15+ years.
- w-m 7y ago
  I totally agree, updating compilers is painful, and can be hard even for smaller projects. But for projects that went through that and actually got the newer compiler working with the C++11 code, I haven't yet seen anything that breaks compilation when then switching the compiler flag to C++14 mode.
- jandrewrogers 7y ago
  You raise a good point about newer compilers doing much deeper analysis of the code than older compilers. I have experienced the horror of compiling an old, nominally clean C++11 code base with the latest version of clang++ and seeing a small avalanche of errors and warnings that weren't picked up by the compiler when that code was written. It creates a lot of work, and frequently the nature of the bugs are not material (i.e. in context they may not produce a runtime fault), but I do find it to be good hygiene. I used to do builds with two different compilers for the same purpose, though that found compiler bugs as often as it found issues in the code.
- d1zzy 7y ago
  Plus, a lot of new library and language features are simply standardized versions of features that mature codebases had their own solutions for years, so "upgrading" to a newer C++ may also imply a long process of deprecating these alternatives in favor of standard ones, and the subtle differences between the two can expose new bugs and issues.
- cpeterso 7y ago
  Here is a list of some real-world examples of bugs that Mozilla had to fix when upgrading from Firefox from C++11 to C++14 to C++17 (still in progress). Many of these are compiler issues from upgrading to clang or gcc versions recent enough to support the new C++ versions, not C++ language changes. https://bugzilla.mozilla.org/showdependencytree.cgi?id=1560664&hide_resolved=0 https://bugzilla.mozilla.org/showdependencytree.cgi?id=15606...
  - dgellow 7y ago
    Your link requires to be logged in to see the actual bug ticket.
gumby 7y ago
> On the other hand, there aren't really any changes in 14 and 17 that break compatibility with code written in 11, at least that I'm aware of. auto_ptr has thankfully be removed, but if you have legacy code that uses it it won't compile under C++17. Of course if you have code that uses auto_ptr you should fix it, but realistically nobody has the time for that.
- ludamad 7y ago
  I mean, if tricky usage of auto_ptr is stopping you, you could probably use a drop-in replacement. But the 'and this adds to the sprint tasks how?' question still isn't answered in a good way
  - TillE 7y ago
    You could probably just find/replace unique_ptr. I'm pretty sure that's what I did a million years ago when auto_ptr was deprecated. C++17 does break some code by removing a few things, but they're pretty trivial and nothing sneaky.
    - tjalfi 7y ago
      clang-tidy has a command to replace auto_ptr with unique_ptr[0]. I haven't used it in anger, though. [0] https://clang.llvm.org/extra/clang-tidy/checks/modernize-replace-auto-ptr.html https://clang.llvm.org/extra/clang-tidy/checks/modernize-rep...
- MauranKilom 7y ago
  Depends on how much it was used. But I was part of the effort to convert to C++17 for our (substantial) C++ code base of ~30 years and it was not painful at all.
- twoodfin 7y ago
  I also ran up against the deprecation of std::mem_fun and std::mem_fun_ref in a recent migration. Easy enough to replace with lambda expressions, but one more hurdle to running C++17 code.

jcranmer 7y ago

> (3) There's no widespread perception that C++14 or later bring compelling language improvements. Constexpr if (introduced in C++17). If you're building a library that uses templated types (and therefore static dispatch instead of virtual functions and dynamic dispatch), then using constexpr if dramatically simplifies the implementation of your code.

saghm 7y ago
I don't think GP was arguing that there weren't any compelling language improvements, just that there isn't a "widespread perception" of those improvements.

CreRecombinase 7y ago

C++11 vs C++14/C++17/C++20 is not python2 vs python3. Because of the emphasis on backwards compatibility, you can often just recompile your C++11 project with the new version of the standard and everything should just work. Backwards compatability also means that the newer versions are only as "complex" as the features you choose to use.

saghm 7y ago
The tricky part of this is that if your project is a library, you're not just opting into having to update your own toolchain, but also that of all your users. This means that a lot of library developers will err on the side of not updating their minimum version, which in turn means application developers don't have as much pressure to update either. This isn't specific to C++ by any means, but I think it does pop up a bit more in this space due to the fact that a lot of developers prefer to just use the default toolchain of their system, so forcing downstream users to update their toolchain could be viewed as a bit more of a maintenance burden.

htns 7y ago

Re (5), I rather feel that the quality of the documentation and communication around modern C++ puts everything else to shame. If you knew java or python in 2009, how are you supposed to quickly catch up with 2019? (Rust also seems to have piled on a lot of additions since 1.0, but I don't use it so I shouldn't speak.) There are books and blogs for everything popular, but it's really a little shocking to me that no other big language has anything that can compare to cppreference.com. This doesn't change what people other than me might be thinking, of course.

dgellow 7y ago
I guess it's a question of habit. I'm learning C++ during my free time since a few months. I find cppreference.com really difficult to parse. I understand way more of the documentation now than when I started because of the bit of experience I gained, but it is written in a way that makes everything sounds really over-complicated. I remember when I googled for something and arrived at the page about "Value category": https://en.cppreference.com/w/cpp/language/value_category https://en.cppreference.com/w/cpp/language/value_category. If you're not already well familiar with the language, this page is really hard to understand IMHO. I found it way easier to deal with Go, C#, and Ruby documentation for example.
- gpderetta 7y ago
  Cppreference is great, but it is not the best place to learn the language.
- east2west 7y ago
  I don't recommend cppreference for novices. It is by no means an easy read. It is a reference, first of all. It enumerates all possible minutiae exhaustively. Unless you are already familiar, to a degree, with most of the topics, reading it is going to be frustrating. The second obstacle is the terminology. C++ defines a lot of terms that are not in common use in other languages. It takes time to be acclimated. The reason that it is popular in the C++ community is that it cuts down legalese a lot when compared to the language standard. Try books first. Meyers and Josuttis write excellent books. The template guide by Vandevoorde and Josuttis is my gateway drug to becoming a language lawyer. It is still hard, but at least manageable.

CoolGuySteve 7y ago

ABI stability of the STL is the biggest issue I've seen. Upgrading from C++11 to C++17 becomes a bust if any of your 3rd party libraries want to pass even a basic std::string. I don't know what the hold up is on modules. Even a basic "this header uses a C++11 namespace" functionality would fix most of the problems. But even better would be something like "extern 'Cwrapper'" that would let you expose C++ objects as a C API with a void* object pointer without having to do the pointless wrapper dance every time. Like make the compiler convert "class Thing { doThing(int a); }" to "typedef void* Thing; Thing_doThing(Thing* this, int a);" automatically so that other languages can call me.

Ididntdothis 7y ago
I don’t understand why they don’t do more about ABI. Compared to C# or java it’s such a pain to share code in C++. To me this would open up a lot of opportunities to create more libraries.
- gpderetta 7y ago
  They do. ABI breaking changes are routinely voted down unless they are really worth it (and the only non backward compatible change that was accepted that I'm aware is the std string changes in C++11).
  - Ididntdothis 7y ago
    Maybe things are better now but in the past almost every new library I added to my projects required a lot of fiddling with headers , link options and other stuff. With C# this is so easy in comparison.
  - steveklabnik 7y ago
    This paper is related and interesting: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1863r0.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p186...
    - 7y ago

dgellow 7y ago

Do you think that will change with introduction of modules? Would that be a feature compeling enough to make people move to newer versions of the standard?

jandrewrogers 7y ago

I don't encounter these barriers in commercial settings. The biggest barrier is compiler support if you target environments with different compiler toolchains. Each new version of C++ brings features and bug fixes that make code simpler. It actually reduces complexity from the perspective of the developer. The forcing function for upgrading C++ versions in my teams is always that it would greatly simplify some immediate problem or allow us to remove a gross (but necessary) hack due to the limitations of prior versions. At least with the LLVM toolchain, upgrades have been nearly issue-free so there is little to recommend not doing it. C++17 is a big upgrade over C++11 functionally. Developers that do not see compelling improvements probably weren't using most of the functionality of C++11 anyway. While the number of features and quirks in standard C++ grows with each version, the subset that a developer needs to remember to write correct idiomatic code is shrinking with each new version as capabilities become more general and the expression of those capabilities simpler. There is a new, simpler, and vastly more capable language evolving out of the old one and you can increasingly live almost entirely within this new language as a developer. I hated classic C++ but I actually really like this new C++, and it allows me to write far less code for the same or better result. There are still many things that C++ can express simply and efficiently that Rust, Julia, etc cannot. If you work on software that can take advantage of that expressiveness (e.g. databases in my case), the cost of changing languages is quite large.

dgellow 7y ago
> There is a new, simpler, and vastly more capable language evolving out of the old one and you can increasingly live almost entirely within this new language as a developer. How is that true in practice? I would expect that once you have a codebase big enough, instead of living only with the new language you still have to deal with (or at least read) code written in previous versions of the language. And so instead of having to know only the modern subset you would have to keep in mind all the potential quirks from previous versions.
- jandrewrogers 7y ago
  Sure, you will have code written in an older idiomatic style but there is some continuity, most C++17 programmers used to be C++11/14 programmers. Upgrading code from e.g. C++11 to C++17 is relatively incremental, typically easily recognized, and can be done opportunistically. Obviously going from C++03 to C++17 would be much more expensive, so that is a bit of a different case. Rapid improvements in code analysis often breaks previously clean builds in newer compilers, so you often find yourself doing hygienic work on old C++ code anyway. This does imply some ongoing maintenance work related solely to keeping the code base consistently "modern". This almost always makes the C++ simpler and more maintainable and often reduces the line count, so it is worth the nominal investment. The massive improvement in template code readability is worth the price of admission all by itself.

microtherion 7y ago

> There's no widespread perception that C++14 or later bring compelling language improvements. I would argue the opposite: C++11 is a fairly different paradigm to C++03, and upgrading an existing code base is a sizable project. But once you get hooked into the concepts it introduces (auto, lambdas, templates, constexpr), each subsequent revision of the language standard introduces some improvement to these concepts that deals with unpleasant edge cases the earlier revision had, so each of them promises to make your existing use cases simpler, at a moderate rewrite expense.

einpoklum 7y ago

(1) It's actually rather sensible, because C++ is famous for its backwards compatibility. So you can use C++14 or C++17 features in some new code while leaving the rest as-is - and gradually refactoring some of it with new features. (2) This used to be the case with C++03 (or C++98), and it changed... (3) I partially disagree and partially claim you're begging the question. You don't have poll results to suggest what people think of C++14. But - C++14 had a lot less changes compared to C++11 or C++17; this was natural considering how the cycle of debate of potential features progressed. The thing is, the fact that C++14 wasn't that revolutionary in terms of features also means it is easier to adopt. If you want more novelty - try C++17; or - try a C++14-dependent library like Eric Niebler's ranges-v3. (4) C++17 allows for writing less complex code in many cases. Specifically, you can significantly reduce the need for template metaprogramming - a particularly hairy part of the language - by using more constexpr functions and if-constexpr in regular functions. And there are other examples. Like Bjarne says: The C++ committee endeavors to "make simple things simple (to write)". So it's a trade-off. (5) Some people switch languages because of workplace decisions or personal preferences, that's true; but people also adopt C++ because of what becomes possible, or easily-expressible, with newer versions of the language. For example, using the ranges library and with C++14 or later, functional programming with C++ has become quite reasonable, borderline pleasant even. --- Bottom line: In my opinion, at this point C++11 has more inertia than momentum. And that's ok. People will progress over time.

nestorD 7y ago
(4) is my main reason for missing C++17 when I am on a project stuck with C++11. I feel that the template metaprogramming framework deserves an overhaul to clean up historical mistakes and keep only the good part.
- einpoklum 7y ago
  In C++ there are almost never any overhauls - it's almost always new functionality that can replace older functionality. That's what compile-time evaluation is to template metaprogramming.
pacman128 7y ago

zelly 7y ago

They will switch to 20 for modules. No. 1 headache is build times. It will literally save money.

paulddraper 7y ago

> here's no widespread perception that C++14 or later bring compelling language improvements. C++14 didn't add a whole lot of new things; it mostly improved on existing features. C++17 adds a number of new things. I would use it just for std::optional and std::variant though.

SamReidHughes 7y ago

C++14’s compelling improvement is initialization in capture lists, so you don’t have to copy into them. I haven’t seen anything compelling beyond that.