4 ms·

> Yeah, all technically the user's fault, The problem is C++'s priorities. Priority #1 is performance, and if you look closely, nearly every single instance of

by titzer 4y ago

> Yeah, all technically the user's fault, The problem is C++'s priorities. Priority #1 is performance, and if you look closely, nearly every single instance of this buggy-program hostile attitude comes down to the language and libraries absolutely refusing to do any kind of dynamic safety checking by default. UB can be traced directly from "it's too hard to reason about the implications of buggy programs" to "well, don't do that, stupid programmer".

deleted 4y ago
[deleted]
vlovich123 4y ago
There's a talk by Scott Meyers (at the D lang conference IIRC), where he methodologically takes apart the claim that priority #1 is performance or 0-cost abstractions. Basically the way the standards body seems to work is there's ~N different concerns and people will whatever set is appropriate to kill proposals. It gives a fantastic illusion of performance being #1, but C++ makes plenty of choices that are misaligned with performance (e.g. variable aliasing that it inherited from C but it let infect the C++ type system too).
- hot_gril 4y ago
  There are tradeoffs. If performance were always #1 with the underlying requirement of portability, you'd be using C. And performance is more of a concern in C++ than in Java. I'm no expert in this, I'm just a guy who's sick of writing web backends in C++ for no reason.
  - pjmlp 4y ago
    Ah the days of ISAPI ATL extensions. :)
  - vlovich123 4y ago
    You'd think so, but C doesn't have the performance crown always either due to language design choices. A big one is aliasing (which languages like Rust and Fortran forbid) which inhibits the ability for very impactful and common low-level optimizations that come up all the time. Performance characteristic differences between C vs C++ are not all that interesting because the language models are so similar (& thus similarly the compilers for them basically have the same model). Indeed, higher level of abstractions can help improve performance as virtual classes will outperform manual attempts at doing similar things (due to devirtualization passes within the compiler). That's actually been a friction point for Rust using LLVM because LLVM is built around the C/C++ language model and it's hard to express certain invariants to it that would result in even more efficient code or you try to use optimization passes that turn out to be broken because they're not really used by the broader C/C++ community (https://github.com/rust-lang/rust/issues/54878 https://github.com/rust-lang/rust/issues/54878).
j16sdiz 4y ago
> Priority #1 is performance, .. No. It's not. It's designed by committee -- impossible to deprecate old misfeatures, trying to entertain everybody but please nobody.
- hot_gril 4y ago
  Plenty of people are pleased with it. It gets the job done, if you're using it for the right job.
- opportune 4y ago
  Deprecating old features is not reasonable for a widely used language. Just look at what happened with Python 3.
  - hot_gril 4y ago
    Yep. If I upgrade my version and just a basic `print` no longer works the same, I go back.
skitter 4y ago
As far as I can tell, Priority #1 is backwards compatibility. For example, std::regex can be slower than launching PHP and running the regex there¹, but that won't be fixed because it would require an ABI break. I'm not sure how that happened, as neither the poor performance nor the unwillingness to change ABI were unknown. Performance seems to not have been the top priority in the design of std::unordered_map either, which requires reference stability and therefore boxing. This got added in 2011, 18 years after the birth of the stl. ¹: https://cor3ntin.github.io/posts/abi/ https://cor3ntin.github.io/posts/abi/
opportune 4y ago
You can implement your own libraries that do this easily. The std libraries have to maintain backwards compatibility and typically solve the base case only - just wrap them to do whatever ref counting or bounds checking you want

by titzer 4y ago

deleted 4y ago

[deleted]

vlovich123 4y ago

There's a talk by Scott Meyers (at the D lang conference IIRC), where he methodologically takes apart the claim that priority #1 is performance or 0-cost abstractions. Basically the way the standards body seems to work is there's ~N different concerns and people will whatever set is appropriate to kill proposals. It gives a fantastic illusion of performance being #1, but C++ makes plenty of choices that are misaligned with performance (e.g. variable aliasing that it inherited from C but it let infect the C++ type system too).

hot_gril 4y ago
There are tradeoffs. If performance were always #1 with the underlying requirement of portability, you'd be using C. And performance is more of a concern in C++ than in Java. I'm no expert in this, I'm just a guy who's sick of writing web backends in C++ for no reason.
- pjmlp 4y ago
  Ah the days of ISAPI ATL extensions. :)
- vlovich123 4y ago
  You'd think so, but C doesn't have the performance crown always either due to language design choices. A big one is aliasing (which languages like Rust and Fortran forbid) which inhibits the ability for very impactful and common low-level optimizations that come up all the time. Performance characteristic differences between C vs C++ are not all that interesting because the language models are so similar (& thus similarly the compilers for them basically have the same model). Indeed, higher level of abstractions can help improve performance as virtual classes will outperform manual attempts at doing similar things (due to devirtualization passes within the compiler). That's actually been a friction point for Rust using LLVM because LLVM is built around the C/C++ language model and it's hard to express certain invariants to it that would result in even more efficient code or you try to use optimization passes that turn out to be broken because they're not really used by the broader C/C++ community (https://github.com/rust-lang/rust/issues/54878 https://github.com/rust-lang/rust/issues/54878).

j16sdiz 4y ago

> Priority #1 is performance, .. No. It's not. It's designed by committee -- impossible to deprecate old misfeatures, trying to entertain everybody but please nobody.

hot_gril 4y ago
Plenty of people are pleased with it. It gets the job done, if you're using it for the right job.
opportune 4y ago
Deprecating old features is not reasonable for a widely used language. Just look at what happened with Python 3.
- hot_gril 4y ago
  Yep. If I upgrade my version and just a basic `print` no longer works the same, I go back.

skitter 4y ago

As far as I can tell, Priority #1 is backwards compatibility. For example, std::regex can be slower than launching PHP and running the regex there¹, but that won't be fixed because it would require an ABI break. I'm not sure how that happened, as neither the poor performance nor the unwillingness to change ABI were unknown. Performance seems to not have been the top priority in the design of std::unordered_map either, which requires reference stability and therefore boxing. This got added in 2011, 18 years after the birth of the stl. ¹: https://cor3ntin.github.io/posts/abi/ https://cor3ntin.github.io/posts/abi/

opportune 4y ago

You can implement your own libraries that do this easily. The std libraries have to maintain backwards compatibility and typically solve the base case only - just wrap them to do whatever ref counting or bounds checking you want