4 ms·

What about performance? The appeal of C was that it translated nicely to pdp-11 instructions with virtually no overhead. Then the appeal of C++ was that it tran

What about performance? The appeal of C was that it translated nicely to pdp-11 instructions with virtually no overhead. Then the appeal of C++ was that it translated nicely to C code (in fact, first versions of C++ were just a preprocessor, passing the job down to the actual C compiler), and you could still insert ASM code if needed. All these new features introduce some run-time overhead, it seems.

gollum999 2y ago
Which features in particular? One of C++'s core tenants is (and has been since the 90's) zero-cost abstractions. Or really, "zero-runtime-cost abstractions"; compile times tend to increase. Obviously some abstractions necessarily require more computation (e.g. raw pointers vs reference-counted smart pointers). But in many cases new features (if implemented correctly!) give better semantics and additional compile-time safety while still compiling down to equivalent binary.
- einpoklum 2y ago
  So, here's the thing: Officially, C++ is committed to "What you don’t use, you don’t pay for (zero-overhead rule)”. This is item 2.4 in the reaffirmed design goals: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3466r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p34... but the current ABI _forces_ some abstractions to have unnecessary cost. For example: "Why can a T* be passed in register, but a unique_ptr<T> cannot?" https://stackoverflow.com/q/58339165/1593077 https://stackoverflow.com/q/58339165/1593077 another example is improvements in the implementation of parts of the standard library. And that is not the only thing that prevents zero-cost abstraction. C++ does not support pointer restrction, see: https://stackoverflow.com/tags/restrict-qualifier/info https://stackoverflow.com/tags/restrict-qualifier/info in practice, compilers support it for some contexts. (Anoter, minor issue is the discrepancy of "No viral annotation" and "no heavy annotation" with the need to mark things noexcept to avoid exceptio handling overhead.)
  - nickelpro 2y ago
    For unique_ptr: This is not a problem that can be solved by the standards committee, they don't control the SysV / Itanium / Win64 standards. You can still use raw pointers if you want to, nothing has been lost from C. For restrict: Universally supported as `__restrict`, thus not a priority for anyone to "officially" solve. Most major performance complaints fall into this category. Eg, std::regex is bad, sure, but nobody uses std::regex so fixing it doesn't matter.
    - einpoklum 2y ago
      > This is not a problem that can be solved by the standards committee SysV/Itanium/Win64 knows nothing about the abstract difference between a 64-bit value and a 64-bit value inside a class instance. Don't see what prevents the solution from the language side. > Universally supported as `__restrict` 1. That's not C++. If we're talking about what compilers can offer outside the language standard - that's a different discussion. We don't have to standardize, then, just get a working implementation somewhere and lobby other compiler-makers to adopt it. A compiler might implement Baxter's "safe mode" idea as a non-standard extension, for example. 2. Even the compilers supoorting `__restrict` only support it for parameters of functions - nowhere else.
      - nickelpro 2y ago
        > Don't see what prevents the solution from the language side. The standard has nothing to say about calling convention. Calling conventions are defined by the ABI standards. unique_ptr is a class template, how a class is passed between routines is defined by ABI standards, ergo how unique_ptr is passed between routines is defined by the ABI standards. I don't know what else you're implying here. Unless you're saying we should have language-level smart pointers, not class templates, in which case yes that's an awful idea. > That's not C++... If you're arguing about some abstract, Platonic ideal of C++ that is divorced from the actual implementations that exist in the world, I don't know what your point is. We write code to be compiled by compilers that exist, not printed out and contemplated in a museum. The compilers support __restrict, people use it all the time, so its not a problem. > Even the compilers... Where else do you want it? What would its meaning even be to something like a member variable? Restrict is pointless in any scenario that doesn't involve a potentially aliasing ABI boundary, ie, function parameters. In every other scenario it is ignored.

gollum999 2y ago

Which features in particular? One of C++'s core tenants is (and has been since the 90's) zero-cost abstractions. Or really, "zero-runtime-cost abstractions"; compile times tend to increase. Obviously some abstractions necessarily require more computation (e.g. raw pointers vs reference-counted smart pointers). But in many cases new features (if implemented correctly!) give better semantics and additional compile-time safety while still compiling down to equivalent binary.

einpoklum 2y ago
So, here's the thing: Officially, C++ is committed to "What you don’t use, you don’t pay for (zero-overhead rule)”. This is item 2.4 in the reaffirmed design goals: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3466r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p34... but the current ABI _forces_ some abstractions to have unnecessary cost. For example: "Why can a T* be passed in register, but a unique_ptr<T> cannot?" https://stackoverflow.com/q/58339165/1593077 https://stackoverflow.com/q/58339165/1593077 another example is improvements in the implementation of parts of the standard library. And that is not the only thing that prevents zero-cost abstraction. C++ does not support pointer restrction, see: https://stackoverflow.com/tags/restrict-qualifier/info https://stackoverflow.com/tags/restrict-qualifier/info in practice, compilers support it for some contexts. (Anoter, minor issue is the discrepancy of "No viral annotation" and "no heavy annotation" with the need to mark things noexcept to avoid exceptio handling overhead.)
- nickelpro 2y ago
  For unique_ptr: This is not a problem that can be solved by the standards committee, they don't control the SysV / Itanium / Win64 standards. You can still use raw pointers if you want to, nothing has been lost from C. For restrict: Universally supported as `__restrict`, thus not a priority for anyone to "officially" solve. Most major performance complaints fall into this category. Eg, std::regex is bad, sure, but nobody uses std::regex so fixing it doesn't matter.
  - einpoklum 2y ago
    > This is not a problem that can be solved by the standards committee SysV/Itanium/Win64 knows nothing about the abstract difference between a 64-bit value and a 64-bit value inside a class instance. Don't see what prevents the solution from the language side. > Universally supported as `__restrict` 1. That's not C++. If we're talking about what compilers can offer outside the language standard - that's a different discussion. We don't have to standardize, then, just get a working implementation somewhere and lobby other compiler-makers to adopt it. A compiler might implement Baxter's "safe mode" idea as a non-standard extension, for example. 2. Even the compilers supoorting `__restrict` only support it for parameters of functions - nowhere else.
    - nickelpro 2y ago
      > Don't see what prevents the solution from the language side. The standard has nothing to say about calling convention. Calling conventions are defined by the ABI standards. unique_ptr is a class template, how a class is passed between routines is defined by ABI standards, ergo how unique_ptr is passed between routines is defined by the ABI standards. I don't know what else you're implying here. Unless you're saying we should have language-level smart pointers, not class templates, in which case yes that's an awful idea. > That's not C++... If you're arguing about some abstract, Platonic ideal of C++ that is divorced from the actual implementations that exist in the world, I don't know what your point is. We write code to be compiled by compilers that exist, not printed out and contemplated in a museum. The compilers support __restrict, people use it all the time, so its not a problem. > Even the compilers... Where else do you want it? What would its meaning even be to something like a member variable? Restrict is pointless in any scenario that doesn't involve a potentially aliasing ABI boundary, ie, function parameters. In every other scenario it is ignored.