[eslaught]

> I feel like C++ proves exactly that you can't.

Depends on what you mean. At a minimum, I think it's clear that C++ has avoided a Python 2/3 style split in the community. This means that otherwise relatively conservative users (I'm thinking of users on supercomputers in this case) are upgrading quickly to new C++ compilers and standard versions.

On the other hand, C++ has always been a kitchen sink sort of language, and it is even more so now. As codes age, they tend to grow and not shrink in the feature set they use, and so long-lived codes will probably never completely escape the demons of previous versions, regardless of how nice the shiny new features are.

[dzdt]

Lol. At my work I am still eagerly awaiting the arrival of C++11.

[EpicEng]

That's not the point. The point is that, when you get it, you won't encounter a list of breaking changes and your code will continue to work.

[ernst_klim]

>you won't encounter a list of breaking changes and your code will continue to work.

Sure, that's why my gstreamermm app refused to build when I switched to --std=c++17

[EpicEng]

Here's the list: https://stackoverflow.com/questions/6399615/what-breaking-ch...

Was it one of those? If not then the fault was with your code or the implementation, not the spec. The language itself is very good at maintaining backward compatibility.

[ernst_klim]

>you won't encounter a list of breaking changes

>list of breaking changes

Yeap, some shit with smart pointers in glibmm, didn't investigated much.

https://bugzilla.redhat.com/show_bug.cgi?id=1438766

[EpicEng]

>C++17 will remove support for old-style exception specifications

Right, you've been told for some time that those were deprecated. At some point deprecated features go away.