6 ms·

For games, C++ becomes a much simpler language since game code bases usually ignore the C++ stdlib (at least mostly, and for good reasons, e.g. see [0]). And wi

For games, C++ becomes a much simpler language since game code bases usually ignore the C++ stdlib (at least mostly, and for good reasons, e.g. see [0]). And without the stdlib C++ is actually kinda-sorta okay-ish. Related, the main problem with the C++ ecosystem is that everybody carves out their own language subset, so it's not one ecosystem but many ecosystems with contradicting styles and language/stdlib subsets. This makes code reuse via libraries much harder than it should be. [0] https://hftuniversity.com/post/the-c-standard-library-has-been-walking-itself-back-for-fifteen-years-and-the-receipts-are-public https://hftuniversity.com/post/the-c-standard-library-has-be...

Chaosvex 5mo ago
That article probably isn't the best source to cite. You can look at the discussions on it elsewhere, although I'd just dismiss it as slop. The standard library is mostly fine to use unless you have specific needs. The bit about libraries is nonsense, sorry.
- flohofwoe 5mo ago
  The article might be slop, but the problems described in it are definitely real ;)
  - Chaosvex 5mo ago
    Grossly exaggerated or misunderstood in many cases. Some of their arguments are just flat-out wrong. I mean, why are they blaming the standard library for inherent properties of linked lists? Yeah, you don't want to use them without good reason. That's just called picking the right data structure for the job, not a flaw with the standard library. Some of the other choices were tradeoffs between performance and usability. The standard maps have stable iterators, whereas third-party implementations almost never do because you can write faster implementations if you're willing to live without those guarantees. Was it the right choice in hindsight? Maybe, maybe not. I'd personally like to see a namespaced versioned standard library but like that's ever going to happen
    - flohofwoe 5mo ago
      As I understood the article, the main critique is that the stdlib has no concept of deprecation and breaking backward compatibility. E.g. the C++ committee is quick to add badly designed features to the stdlib but then can't roll them back when people actually realize that those new features are useless for most real-world code.
      - Chaosvex 5mo ago
        Yet they spend a lot of time complaining about features that were deprecated or removed.
      - zabzonk 5mo ago
        Badly designed things get replaced. For example unique_ptr replaced auto_ptr. I'm not sure if the language standard actually supports the term "deprecation" though. Edit: Also not sure what can possibly be downvoted here.
        johannes1234321 5mo ago
        auto_ptr is an exception. Not the rule. Regular expressions in C++ are an example "everybody" advises against using, but it's still there. vector<bool> will stay forever and so on.
        bregma 5mo ago
        ISO/IEC 14882 contains many uses of the word "deprecation", including all the sections of Appendix D that explicitly lists all of the deprecated and removed features of the language and library.
        deleted 5mo ago
        [deleted]
      - domenicd 5mo ago
        I'm not sure this is a winnable game for programming languages. - Keep a small stdlib, like JavaScript (especially earlier JavaScript): everyone complains about missing features, warring communities form around jQuery promises vs. Promises/A+ vs. callbacks, supply chain attacks, left-pad/is-even dependencies, etc. - Grow a big stdlib while keeping backward compatibility, like C++: lots of cruft left around that must never be used, sitting next to newer stuff with similar names. People complain about the bloat. - Grow a big stdlib and then break backward compatibility, like Python 2 -> 3: everyone is sad, the ecosystem churns for years. I admit there are probably better and worse versions of each strategy, e.g., it seems to me like JavaScript's slow-but-steady accretion of primitives over time has gone OK, and it seems like apart from Python 2 -> 3 some of the PEPs I see for deprecations and replacements are reasonable. But no language has ever hit on a strategy that everyone loves, as far as I can tell.
samiv 5mo ago
If you don't use the STL you end up re-implementing it yourself. Usually poorly.
- flohofwoe 5mo ago
  > Usually poorly. On the contrary. You can focus exactly on the features the higher level game code needs. The C++ stdlib is (for the most part) poorly designed, usually poorly implemented, the main reason for slow build times, and its complexity explodes because it needs to consider all edge cases that most code bases don't ever trigger. A specialized dynamic array class in a few hundred lines (at most!) and with just the required features is much more useful than the 20kloc monster that's pulled in with `#include <vector>` and which doesn't even do bounds checking in the 'idiomatic' usage.
  - samiv 5mo ago
    Yes I don't disagree that sometimes a specific container or a data structure is great for the problem. Problem is that most of the game code and related code (so tooling,editor, auxiliary engine code) does need a typical STL type functionality and then when the org has "omg no STL" blanket rule someone ends up implementing STL and that's almost always worse than the STL that ships with the tool chain. Even worse..it'll be missing features and data structures and then people have to write sub-optimal code to work around it's limitations.
    - bluGill 5mo ago
      Top tier game orgs are often large enough to have good people write their own library with the correct compromises. They also tend to need micro performance improvements enough to be worth it. Most of the rest of us STL is good enough.
      - tarnith 5mo ago
        Yeah, EA open sourced their STL, although now that C++23 is supported (aside from on MSVC? Still not flat_map there?!?) there is some replication in the STL. Not uncommon for audio companies to also write their own containers and internal STL for ex. plugins as well.
herr_shield 5mo ago
I fully agree. In my personal project, I ended up using the STL to get off the ground, but in the end I replaced pretty much everything with custom-written code. Once you get rid of the STL, compile times get so much better. With modern c++23 features, templates actually become really convenient to write, and at the core there is a really useful and pleasant to use language. I try to avoid c++ libraries and instead rely on c-style APIs. Usually the c++ style libraries force you into using the STL, which comes with a heavy tax on compile times, without much benefit in comfort of use.
- GnarfGnarf 5mo ago
  What, you rewrote std::deque? Whew!
  - spwa4 5mo ago
    Rewriting at least std::vector was a standard way to prep for a Google interview. And std::map if you wanted bonus points or a level up. Also, really interesting to do.
  - wavemode 5mo ago
    Deque is one of the easier ones. I echo the parent commenter - the STL has a massive negative impact on compile times. And for what? The STL is not even fast. The way the standards are written, std::unordered_map has to be implemented as a tree rather than a flat open-addressing hashtable, which would've been far superior due to cache locality. For my own project I rolled my own string, string_view, map, set, optional, variant, and vector. Only took maybe a day. And that day has paid dividends, as my clean debug builds literally take 3 seconds now.
    - drivebyhooting 5mo ago
      Unordered map is a hash map with separate chaining.
jibal 5mo ago
Your citation refers to the register keyword and trigraphs, among other language features -- the author seems to have forgotten his own point, among a number of other inconsistencies and contradictions, and at times seems to go out of his way to come across as a jerk, e.g., "This is what fifteen years of standards work on an eight-letter keyword looks like". People love to rag on the standards committee. I was on X3J11, the C Language Standards Committee, in 1989 ... in fact, due to alphabetical order I was the first person on the planet to vote to approve the C language standard -- the one that first standardized register and trigraphs. Standards work is hard and everyone hates you for it.
- flohofwoe 5mo ago
  The C Committee is fine and doing great work! The C++ Committee could actually learn a thing or two from how things are done on the C side.
  - pjmlp 5mo ago
    Like strings and arrays? Or _Keywords with an additional header file? Maybe something_ names as proper namespaces are too hard? One could mention better testing before adding features to the standards, but then C99 VLAs happened.

Chaosvex 5mo ago

That article probably isn't the best source to cite. You can look at the discussions on it elsewhere, although I'd just dismiss it as slop. The standard library is mostly fine to use unless you have specific needs. The bit about libraries is nonsense, sorry.

flohofwoe 5mo ago
The article might be slop, but the problems described in it are definitely real ;)
- Chaosvex 5mo ago
  Grossly exaggerated or misunderstood in many cases. Some of their arguments are just flat-out wrong. I mean, why are they blaming the standard library for inherent properties of linked lists? Yeah, you don't want to use them without good reason. That's just called picking the right data structure for the job, not a flaw with the standard library. Some of the other choices were tradeoffs between performance and usability. The standard maps have stable iterators, whereas third-party implementations almost never do because you can write faster implementations if you're willing to live without those guarantees. Was it the right choice in hindsight? Maybe, maybe not. I'd personally like to see a namespaced versioned standard library but like that's ever going to happen
  - flohofwoe 5mo ago
    As I understood the article, the main critique is that the stdlib has no concept of deprecation and breaking backward compatibility. E.g. the C++ committee is quick to add badly designed features to the stdlib but then can't roll them back when people actually realize that those new features are useless for most real-world code.
    - Chaosvex 5mo ago
      Yet they spend a lot of time complaining about features that were deprecated or removed.
    - zabzonk 5mo ago
      Badly designed things get replaced. For example unique_ptr replaced auto_ptr. I'm not sure if the language standard actually supports the term "deprecation" though. Edit: Also not sure what can possibly be downvoted here.
      - johannes1234321 5mo ago
        auto_ptr is an exception. Not the rule. Regular expressions in C++ are an example "everybody" advises against using, but it's still there. vector<bool> will stay forever and so on.
      - bregma 5mo ago
        ISO/IEC 14882 contains many uses of the word "deprecation", including all the sections of Appendix D that explicitly lists all of the deprecated and removed features of the language and library.
      - deleted 5mo ago
        [deleted]
    - domenicd 5mo ago
      I'm not sure this is a winnable game for programming languages. - Keep a small stdlib, like JavaScript (especially earlier JavaScript): everyone complains about missing features, warring communities form around jQuery promises vs. Promises/A+ vs. callbacks, supply chain attacks, left-pad/is-even dependencies, etc. - Grow a big stdlib while keeping backward compatibility, like C++: lots of cruft left around that must never be used, sitting next to newer stuff with similar names. People complain about the bloat. - Grow a big stdlib and then break backward compatibility, like Python 2 -> 3: everyone is sad, the ecosystem churns for years. I admit there are probably better and worse versions of each strategy, e.g., it seems to me like JavaScript's slow-but-steady accretion of primitives over time has gone OK, and it seems like apart from Python 2 -> 3 some of the PEPs I see for deprecations and replacements are reasonable. But no language has ever hit on a strategy that everyone loves, as far as I can tell.

samiv 5mo ago

If you don't use the STL you end up re-implementing it yourself. Usually poorly.

flohofwoe 5mo ago
> Usually poorly. On the contrary. You can focus exactly on the features the higher level game code needs. The C++ stdlib is (for the most part) poorly designed, usually poorly implemented, the main reason for slow build times, and its complexity explodes because it needs to consider all edge cases that most code bases don't ever trigger. A specialized dynamic array class in a few hundred lines (at most!) and with just the required features is much more useful than the 20kloc monster that's pulled in with `#include <vector>` and which doesn't even do bounds checking in the 'idiomatic' usage.
- samiv 5mo ago
  Yes I don't disagree that sometimes a specific container or a data structure is great for the problem. Problem is that most of the game code and related code (so tooling,editor, auxiliary engine code) does need a typical STL type functionality and then when the org has "omg no STL" blanket rule someone ends up implementing STL and that's almost always worse than the STL that ships with the tool chain. Even worse..it'll be missing features and data structures and then people have to write sub-optimal code to work around it's limitations.
  - bluGill 5mo ago
    Top tier game orgs are often large enough to have good people write their own library with the correct compromises. They also tend to need micro performance improvements enough to be worth it. Most of the rest of us STL is good enough.
    - tarnith 5mo ago
      Yeah, EA open sourced their STL, although now that C++23 is supported (aside from on MSVC? Still not flat_map there?!?) there is some replication in the STL. Not uncommon for audio companies to also write their own containers and internal STL for ex. plugins as well.

herr_shield 5mo ago

I fully agree. In my personal project, I ended up using the STL to get off the ground, but in the end I replaced pretty much everything with custom-written code. Once you get rid of the STL, compile times get so much better. With modern c++23 features, templates actually become really convenient to write, and at the core there is a really useful and pleasant to use language. I try to avoid c++ libraries and instead rely on c-style APIs. Usually the c++ style libraries force you into using the STL, which comes with a heavy tax on compile times, without much benefit in comfort of use.

GnarfGnarf 5mo ago
What, you rewrote std::deque? Whew!
- spwa4 5mo ago
  Rewriting at least std::vector was a standard way to prep for a Google interview. And std::map if you wanted bonus points or a level up. Also, really interesting to do.
- wavemode 5mo ago
  Deque is one of the easier ones. I echo the parent commenter - the STL has a massive negative impact on compile times. And for what? The STL is not even fast. The way the standards are written, std::unordered_map has to be implemented as a tree rather than a flat open-addressing hashtable, which would've been far superior due to cache locality. For my own project I rolled my own string, string_view, map, set, optional, variant, and vector. Only took maybe a day. And that day has paid dividends, as my clean debug builds literally take 3 seconds now.
  - drivebyhooting 5mo ago
    Unordered map is a hash map with separate chaining.

jibal 5mo ago

Your citation refers to the register keyword and trigraphs, among other language features -- the author seems to have forgotten his own point, among a number of other inconsistencies and contradictions, and at times seems to go out of his way to come across as a jerk, e.g., "This is what fifteen years of standards work on an eight-letter keyword looks like". People love to rag on the standards committee. I was on X3J11, the C Language Standards Committee, in 1989 ... in fact, due to alphabetical order I was the first person on the planet to vote to approve the C language standard -- the one that first standardized register and trigraphs. Standards work is hard and everyone hates you for it.

flohofwoe 5mo ago
The C Committee is fine and doing great work! The C++ Committee could actually learn a thing or two from how things are done on the C side.
- pjmlp 5mo ago
  Like strings and arrays? Or _Keywords with an additional header file? Maybe something_ names as proper namespaces are too hard? One could mention better testing before adding features to the standards, but then C99 VLAs happened.