Hacker News Reader

Comment by 29athrowaway | Hacker News Reader

They should simply kill the compatibility and provide a migration tool. clang-tidy provides the modernize module which can help.

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.

View on HN

> C++11 is 11 years old. If you haven't modernized your code base in 11 years you never will.

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.

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

It was certainly an ... interesting experience. But it would have been much, much more unpleasant if we had to write new code 90s-style, too.

OTOH if we tried to rewrite the whole thing from scratch, we wouldn't ship a new feature for many years - only new bugs.

"I stopped caring 20 years ago" achievement unlocked.

Not everything needs to be rewritten. And a lot of issues can be introduced in rewrites which have nothing to do with the improved resource management that RAII style development brings.

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.

> For example, if you port numeric libraries are you sure you maintain the same guarantees for numerical stability?

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 an exhaustive test suite for your important numeric libraries, 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.

How a lib where you don't even know whether it computes correct results can be called "best"?

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:

https://yuri.is/not-julia/

A house of cards… :-(

This is normal for open source. You get what you pay for, and nobody is paying for test suites for potential future users to freeload off of. Why would numerical libraries be any different from OpenSSL pre-heartbleed? And how would you fix this issue without spending other people's time and money on things they don't want to spend it on?

This is why subtle compiler rule changes are so potentially devastating.

Then use an old compiler and be on your own.

It seems you know better than the C++ standard committee and Bjarne Stroustrup anyways.

https://www.stroustrup.com/bs_faq2.html#renew

The C++ standard committee has a lot of internal disagreement on many topics, presenting them as a unified body is disingenuous. What I state is the position of a sizeable minority.

And yes, you shouldn't use realloc... but what should you do if your buffer size is more than half of your physical memory?

Reply on news.ycombinator.com