3 ms·

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

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.
  - still_grokking 4y ago
    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 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/ https://yuri.is/not-julia/ A house of cards… :-(
    - snovv_crash 4y ago
      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.
29athrowaway 4y ago
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 https://www.stroustrup.com/bs_faq2.html#renew
- snovv_crash 4y ago
  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?

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.
- still_grokking 4y ago
  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 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/ https://yuri.is/not-julia/ A house of cards… :-(
  - snovv_crash 4y ago
    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.

29athrowaway 4y ago

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 https://www.stroustrup.com/bs_faq2.html#renew

snovv_crash 4y ago
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?