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.

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

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.

Here is a proposal (from CppCon 2019) to create C++ epochs to drop support for old misfeatures in new code (inspired by Rust's epochs). Code written in the new epoch would still be fully backwards-compatible with older C++ versions and compilers.

https://www.youtube.com/watch?v=PFdKFoQxRqM

Here’s the corresponding paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p188...

So you'll not only need to know all these sublanguages (epochs) but also how they interact with each other, especially when you need to refactor code that needs to cross these "epoch boundaries" (refactor the functionality not just to "upgrade" to a different epoch). Who comes up with that stuff? :-/

How does a developer who is new to C++ learn just the modern idiomatic style? Is there a "C++, the good parts"?

C++ Crash Course: https://lospi.net/c/c++/programming/developing/software/2019...

C++ 17: https://leanpub.com/cpp17 https://leanpub.com/cpp17indetail

There is this: http://www.stroustrup.com/tour2.html

This has been my experience also. Of course you can't forget the old stuff if you're maintaining an old codebase. But, I'm grateful to use lambdas, std algorithm, if constexpr, and fold expressions instead of boilerplate classes, bespoke loops, SFINAE hackery, and recursive variadic functions. There is less wizardry necessary than in the past.

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.

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.

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.

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.

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.

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=15606...

Your link requires to be logged in to see the actual bug ticket.

Oops. Sorry! Here is a different view of the bugs. I verified this list didn't require Bugzilla account.

https://bugzilla.mozilla.org/buglist.cgi?bug_id=1396098%2C13...

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

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.

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.

all compilers have ways to reinstate them to make porting easier, e.g. /D_HAS_AUTO_PTR_ETC=1 on msvc, -D_LIBCPP_ENABLE_CXX17_REMOVED_FEATURES=1 on clang...

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

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.

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

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.

What's the issue with abi stability? GCC broke the Library ABI with C++11 but the old ABI was still available. I thi k it still available in C++14 and 17 mode.

If you switched to the new ABI with c++11 then c++17 as far as I know brings no new breakages.

No, std::string definitely changed between c++11 and c++14. It could be an implementation detail between different libstdc++ versions for the g++ version that supported c++14, but the incompatibility was definitely there.

> No, std::string definitely changed between c++11 and c++14. It could be an implementation detail between different libstdc++ versions for the g++ version that supported c++14, but the incompatibility was definitely there.

that is a problem with your distribution (and the reason why using distro packages sucks for development), not with C++.

The ABI only changes if you change the value of _GLIBCXX_USE_CXX11_ABI with libstdc++

See : https://gcc.godbolt.org/z/QLbjjo

Your example breaks if you change the C++11 pane to GCC 4.9 or earlier, which is the default in CentOS 7 and Ubuntu 14.04.

Considering that was only 5 years ago, I wouldn't consider this a stable ABI.

but again you can revert to gcc-4.9 behaviour with -D_GLIBCXX_USE_CXX11_ABI=0

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.

ABIis hard because C++ structures are typically more complex than C structures. While the C documentation could simply include the struct (and the ABI would constrain padding, etc), consider a simple std::string, which may (OK, will) have small string optimization: different runtime libraries might make different tradeoffs as to how to do this. You'd have to constrain the entire standard library for your platform which could forestall improvements down the road. The committee already unwittingly made that mistake with std::map and doesn't want to make that mistake again.

C++ also insists on inlining code extensively across the provider/client boundary, so if the offset of any data element changes the binary library is no longer backwards compatible.

This is exacerbated by the lack of usability in compilation toolchains that promotes header-only libraries just for build simplicity and for which the data structures often won't be compatible across .so boundaries.

Not dissing your comment, just pointing out that the committee is not just aware of the problem but slowly doing what it can to address them. C++17 and C++20 have a bunch of features to improve both of these factors.

There are also a number of features not really intended for user code designed to help make libraries faster, and more stable. The downside of course is, well, just look at library source. But really the source to the C standard library has similar issues.

I don't like header-only libraries because they slow down compilation, and slowly the trend is starting to abate.

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

This paper is related and interesting: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p186...

Thanks for the link, a good read.

As somebody who kicks C++'s tires once in a while and is always put off by the incredible complexity of the language, and the complexity and friction and fragility of its workflow, I was sad not to see any explicit mention of pairing an ABI break with removal of the bad parts. (Yeah, I know, that might mean source-level backwards incompatibility...) Makes me wonder if it's ever even discussed at a high level.

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.

Sounds like a job for an llvm tool. The parse tree is exposed, doing the transform shouldn't be ridiculous? Are you keen enough?

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.

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

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.

> The following expressions are lvalue expressions: [...] a string literal, such as "Hello, world!"

That's pretty interesting. I'm not even sure how to test the effect of

  "Hello, world!" = <something>

I imagine the reason this is allowed has something to do with how strings decay into pointers.

> I found it way easier to deal with ... Ruby documentation for example.

Maybe in documentation detailing the methods available, but as far as I know, there's no official spec for the syntax nor the details of the semantics of the language.

Cppreference is great, but it is not the best place to learn the language.

I agree that cppreference is amazing and is my only c++ link in my browser favourites. Documentation is typically clear and succinct. And its a wiki!

Not a fan of the spongers that scrape it though.

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

(1) I know of one problem with C++17 and old code. C++17 removed throw specifications from the language (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p000...) . We use third party libraries that contain these which keep us from using C++17.

This feature was already deprecated in C++11...

Also, this is an "easy" breakage, in that it was glaringly obvious. That is, you didn't encounter a strange compilation bug and had to investigate why it occurred, or got different run-time behavior of the same code.

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

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.

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

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.

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.

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

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.

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

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?

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

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.