I am just worried that some proponents of "move fast and break things" might be undervaluing what they are breaking, although C++ committees are are generally good about backward compatibility.
If the only side effect of breaking backwards compatibility is making the people that write C++ as if it was C89 irritated and upset, then that's probably a good thing, let's do it more.
C++11 is 11 years old. If you haven't modernized your code base in 11 years you never will.
If you are using ancient C++, compiler security updates are the least of your security concerns.
If you have code that nobody understands and cannot be touched, you should see that as the real problem and an urgent call to action to fix it, not modernization.
That doesn't make it a dead codebase. New code still gets written - and it helps when it can be written using newer, better techniques while working nicely with old code. I once worked on a codebase that had ancient code from mid-90s with explicit COM AddRef/Release side by side with C++11 lambdas and TMP.
Sounds like pure joy.
OTOH if we tried to rewrite the whole thing from scratch, we wouldn't ship a new feature for many years - only new bugs.
For example, if you port numeric libraries are you sure you maintain the same guarantees for numerical stability? If you are porting containers, do your new backing-array growth strategies achieve the same efficiency as using realloc? Do your new threading primitives have equivalent efficiency on all of the target architectures?
I would prefer to have warnings, or even errors, for 'known bad behaviour' that are enabled by default with new standards - think along the lines of `-fpermissive`. Forcing people to suppress these means that the onus is on them to accept the risks their choices bring.
However, just as with things like void*, the new standards are bringing in their own footguns. Ranges have pointer semantics, not value semantics, for example, which is totally non-obvious and actually means a lot of use cases for ranges just aren't possible. Newer isn't necessarily better, the people writing the original standards were brilliant as well and had their own insights which we now forget.
But your test suite would catch any issues, wouldn't it?
You have an exhaustive test suite for your important numeric libraries, right?
> If you are porting containers, do your new backing-array growth strategies achieve the same efficiency as using realloc? Do your new threading primitives have equivalent efficiency on all of the target architectures?
The benchmarks suite, which is part of your exhaustive test suite, and is guarding against performance regressions would catch any issues for sure!
You have a benchmarks suite to protect against performance degradation, right?
> You have a benchmarks suite to protect against performance degradation, right?
In theory, in a perfect world, yes.
In practice, people use open source libraries like Eigen because they are the best, not because of their extensive test coverage. Doing things which might break these libraries will fork the community.
Only because something spits out numbers really fast doesn't say anything about the quality of this something. Especially when considering that optimizing for speed comes most times with very hacky code! This, plus the fact that this code is usually written by laymen (scientist aren't software engineers!) makes such things very questionable.
After looking into scientific computing and the usual software "quality" there I lost quite some trust in anything that comes out of there. This was actually very disillusionary and extremely sad to find out. This could even destroy the broader trust in science in general (as everything today in this field depends on statistics calculated by computers). This would be an catastrophic outcome! But most people would currently even deny the existence of an issue…
Related (together with the parent): https://news.ycombinator.com/item?id=34224186
Also related as people (scientists!) got blinded by the promise of speed without considering correctness:
A house of cards… :-(
This is why subtle compiler rule changes are so potentially devastating.
It seems you know better than the C++ standard committee and Bjarne Stroustrup anyways.
And yes, you shouldn't use realloc... but what should you do if your buffer size is more than half of your physical memory?