4 ms·

Your specific gripes seem reasonable (I suspect design-by-committee plays a big part), but: > I really wish the std would drop this pretense and focus on C++'s

Your specific gripes seem reasonable (I suspect design-by-committee plays a big part), but: > I really wish the std would drop this pretense and focus on C++'s strong point: Continue being the fastest systems language possible. You've essentially described C, not C++. C++ has a different philosophy and makes different trade-offs. C++ is at least still pretty committed to the you only pay for what you use principle. As far as I know RTTI is the only real exception (corrections welcome), but even RTTI can be disabled in many compilers. Some of your gripes with the standard library can be addressed with libraries, perhaps from the Boost project.

gafferongames 3y ago
> C++ is at least still pretty committed to the you only pay for what you use principle. As far as I know RTTI is the only real exception (corrections welcome), but even RTTI can be disabled in many compilers. Compile time would also be an exception.
- throwaway81523 3y ago
  I had a program that had to parse a lot of integers like "12345". The std way to do it was an order of magnitude slower than writing my own simple parsing code. I have no idea what the std version was doing, but it was crazy to see my program's execution time (measured in hours) dominated by int parsing. The handwritten version eliminated that.
  - leopoldj 3y ago
    You didn't say which std function you were using that was slow. But std::from_chars performs a lot faster than std::stoi et al due to many reasons.
    - throwaway81523 3y ago
      Yeah I don't remember what I originally used. It might have been stoi but it might have been iostream.
- MaxBarraclough 3y ago
  Even there, you can use a subset of C++ and get pretty good compile times. Worse than C, as you're still dragging around the full weight of a C++ compiler, but still.
IAmLiterallyAB 3y ago
> You've essentially described C I'd disagree pretty strongly with that. C is more focused on being relatively simple to implement and backwards compatibility with the past 50 years. (I read a blog post by a C committee member talking about that recently, wish I could find the link) Just look at the garbage fire which is the standard library. qsort. strtok. rand. C++ should (in theory at least) be able to match or surpass C for _any_ performance benchmark, because it simply gives you more tools in your toolbox. For example, C is never going to be able to beat std::sort because it can't monomorphize in the compare function. I'm not saying C++ is perfect either (looking at you unordered_map and regex). But I am saying people look at C with rose colored glasses.
- trealira 3y ago
  Yeah, I think a degree of complexity is required to achieve being the fastest compiled language. To achieve that, you need stuff like monomorphized templates, actual arrays and slices being distinguished from pointers, well-defined rules on pointers (like Rust's rules about references and mutable references, or strict aliasing in C++), and the freedom to let the compiler reorder structure fields for better alignment and space usage. Runtime polymorphism, like virtual functions in C++, are better as a core language feature rather than something implemented as a struct of function pointers, because that way the compiler can devirtualize some calls. All of these things, I think most C programmers would be against adding to C. And pointer rules are historically controversial; for example, Dennis Ritchie was against adding noalias to C in 1988[1]. [1]: https://www.yodaiken.com/2021/03/19/dennis-ritchie-on-alias-analysis-in-the-c-programming-language-1988/ https://www.yodaiken.com/2021/03/19/dennis-ritchie-on-alias-...
- rewmie 3y ago
  [dead]
CoolGuySteve 3y ago
No, C is not the same as it is less expressive. C++ templates allow for declarative nested inlining into a single compilation unit that is extremely difficult to achieve with C macros. See elsewhere in this thread for discussion of boost, it's not applicable.
- stefan_ 3y ago
  In this thread: all the people that have never looked at C++ disassembly. Maybe the C++ "language server" of your choice should have a mode where it prints all the constructors destructors copy constructors and what not on top of your code? "Zero cost abstraction" is a big fantasy. C++ is the king of hidden control flow and the costs are everywhere.
  - CoolGuySteve 3y ago
    Thanks for the shitty attitude but it sounds more like you're looking at the disassembly of debug builds or don't understand how constexpr/consteval work.
  - RcouF1uZ4gsC 3y ago
    > In this thread: all the people that have never looked at C++ disassembly. Maybe the C++ "language server" of your choice should have a mode where it prints all the constructors destructors copy constructors and what not on top of your code? That tool is called Godbolt at gcc.godbolt.org. This is common enough that Godbolt is a verb with a lot of C++ programmers.
  - IAmLiterallyAB 3y ago
    As someone who reads C++ disassembly/decompilation for a living... Yeah kinda. It depends. If the target code is full of virtual function calls, yeah it gets gross. But if you need dynamic dispatch, C isn't going to be any better, you'll just be reinventing vtables by hand. Similarly, resource acquisition and release happens in C too, you just have to do it by hand instead of letting the destructor do it for you. One ultra gross thing I see all the time in C++ disassembly though: constantly creating copies of a std::string, using them once for a comparison or something trivial, and then throwing them away. Multiple times in the same function. Its the developers fault, they shouldn't be creating new objects, they should be passing a pointer or a string_view or something. Unfortunately, C++ is copy rather than move by default, so its too easy to do this by accident. Another gross thing? (Not C++ specific) 20 functions in a row that are just a single return instruction. Since functions have to have distinct addresses (that's my understanding at least) the compiler/linker can't easily fold identical functions together. Implementations can optimize as long as everything still works (the "as-if" rule). And I know some compilers do. But in practice, it seems they suck at it. So I get to look at 20 lines of assembly in a row that are just `bl`.
fartsucker69 3y ago
the only pay what you use thing is bullshit. because everything you want to use actually costs something. the point being that a better implementation would give you the same things without a cost...
- steveklabnik 3y ago
  "only pay for what you use" means that you do not pay for things you do not use. You are absolutely correct that everything has a cost, but that is not what this slogan is about. The "only" is load-bearing.
deleted 3y ago
[deleted]
andai 3y ago
From my understanding exceptions are also an exception, adding overhead even when not used.

gafferongames 3y ago

> C++ is at least still pretty committed to the you only pay for what you use principle. As far as I know RTTI is the only real exception (corrections welcome), but even RTTI can be disabled in many compilers. Compile time would also be an exception.

throwaway81523 3y ago
I had a program that had to parse a lot of integers like "12345". The std way to do it was an order of magnitude slower than writing my own simple parsing code. I have no idea what the std version was doing, but it was crazy to see my program's execution time (measured in hours) dominated by int parsing. The handwritten version eliminated that.
- leopoldj 3y ago
  You didn't say which std function you were using that was slow. But std::from_chars performs a lot faster than std::stoi et al due to many reasons.
  - throwaway81523 3y ago
    Yeah I don't remember what I originally used. It might have been stoi but it might have been iostream.
MaxBarraclough 3y ago
Even there, you can use a subset of C++ and get pretty good compile times. Worse than C, as you're still dragging around the full weight of a C++ compiler, but still.

IAmLiterallyAB 3y ago

> You've essentially described C I'd disagree pretty strongly with that. C is more focused on being relatively simple to implement and backwards compatibility with the past 50 years. (I read a blog post by a C committee member talking about that recently, wish I could find the link) Just look at the garbage fire which is the standard library. qsort. strtok. rand. C++ should (in theory at least) be able to match or surpass C for _any_ performance benchmark, because it simply gives you more tools in your toolbox. For example, C is never going to be able to beat std::sort because it can't monomorphize in the compare function. I'm not saying C++ is perfect either (looking at you unordered_map and regex). But I am saying people look at C with rose colored glasses.

trealira 3y ago
Yeah, I think a degree of complexity is required to achieve being the fastest compiled language. To achieve that, you need stuff like monomorphized templates, actual arrays and slices being distinguished from pointers, well-defined rules on pointers (like Rust's rules about references and mutable references, or strict aliasing in C++), and the freedom to let the compiler reorder structure fields for better alignment and space usage. Runtime polymorphism, like virtual functions in C++, are better as a core language feature rather than something implemented as a struct of function pointers, because that way the compiler can devirtualize some calls. All of these things, I think most C programmers would be against adding to C. And pointer rules are historically controversial; for example, Dennis Ritchie was against adding noalias to C in 1988[1]. [1]: https://www.yodaiken.com/2021/03/19/dennis-ritchie-on-alias-analysis-in-the-c-programming-language-1988/ https://www.yodaiken.com/2021/03/19/dennis-ritchie-on-alias-...
rewmie 3y ago
[dead]

CoolGuySteve 3y ago

No, C is not the same as it is less expressive. C++ templates allow for declarative nested inlining into a single compilation unit that is extremely difficult to achieve with C macros. See elsewhere in this thread for discussion of boost, it's not applicable.

stefan_ 3y ago
In this thread: all the people that have never looked at C++ disassembly. Maybe the C++ "language server" of your choice should have a mode where it prints all the constructors destructors copy constructors and what not on top of your code? "Zero cost abstraction" is a big fantasy. C++ is the king of hidden control flow and the costs are everywhere.
- CoolGuySteve 3y ago
  Thanks for the shitty attitude but it sounds more like you're looking at the disassembly of debug builds or don't understand how constexpr/consteval work.
- RcouF1uZ4gsC 3y ago
  > In this thread: all the people that have never looked at C++ disassembly. Maybe the C++ "language server" of your choice should have a mode where it prints all the constructors destructors copy constructors and what not on top of your code? That tool is called Godbolt at gcc.godbolt.org. This is common enough that Godbolt is a verb with a lot of C++ programmers.
- IAmLiterallyAB 3y ago
  As someone who reads C++ disassembly/decompilation for a living... Yeah kinda. It depends. If the target code is full of virtual function calls, yeah it gets gross. But if you need dynamic dispatch, C isn't going to be any better, you'll just be reinventing vtables by hand. Similarly, resource acquisition and release happens in C too, you just have to do it by hand instead of letting the destructor do it for you. One ultra gross thing I see all the time in C++ disassembly though: constantly creating copies of a std::string, using them once for a comparison or something trivial, and then throwing them away. Multiple times in the same function. Its the developers fault, they shouldn't be creating new objects, they should be passing a pointer or a string_view or something. Unfortunately, C++ is copy rather than move by default, so its too easy to do this by accident. Another gross thing? (Not C++ specific) 20 functions in a row that are just a single return instruction. Since functions have to have distinct addresses (that's my understanding at least) the compiler/linker can't easily fold identical functions together. Implementations can optimize as long as everything still works (the "as-if" rule). And I know some compilers do. But in practice, it seems they suck at it. So I get to look at 20 lines of assembly in a row that are just `bl`.

fartsucker69 3y ago

the only pay what you use thing is bullshit. because everything you want to use actually costs something. the point being that a better implementation would give you the same things without a cost...

steveklabnik 3y ago
"only pay for what you use" means that you do not pay for things you do not use. You are absolutely correct that everything has a cost, but that is not what this slogan is about. The "only" is load-bearing.

deleted 3y ago

[deleted]

andai 3y ago

From my understanding exceptions are also an exception, adding overhead even when not used.