4 ms·

One major selling point of C++ over other languages is vast volume of the existing C++ code. If some critical portion of which required major updates to cope w

One major selling point of C++ over other languages is vast volume of the existing C++ code. If some critical portion of which required major updates to cope with the removed features, that might not be something that everyone is looking forward to. 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.

29athrowaway 4y ago
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.
- int_19h 4y ago
  > 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.
  - still_grokking 4y ago
    > 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.
    - int_19h 4y ago
      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.
  - 29athrowaway 4y ago
    "I stopped caring 20 years ago" achievement unlocked.
- snovv_crash 4y ago
  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.
  - still_grokking 4y ago
    > 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?
    - snovv_crash 4y ago
      > 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.

29athrowaway 4y ago

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.

int_19h 4y ago
> 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.
- still_grokking 4y ago
  > 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.
  - int_19h 4y ago
    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.
- 29athrowaway 4y ago
  "I stopped caring 20 years ago" achievement unlocked.
snovv_crash 4y ago
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.
- still_grokking 4y ago
  > 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?
  - snovv_crash 4y ago
    > 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.