[flohofwoe]

> 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.

[Chaosvex]

Saying it doesn't even do bounds checking (in release builds) is to miss one of the major points of C++ - not paying for what you don't need. It's not a mistake, it's a feature.

You complain about it not being suitable for game development in one comment but then expect bounds checking in release builds? You're sitting in multiple lanes at the same time.

NIH implementations are usually grossly inferior because as it turns out, it's quite hard to get it right and those edge-cases aren't important until you start getting bitten by them when you'd rather be shipping features.

[flohofwoe]

> bounds checking in release builds

Bounds checking overhead is negligible for all but the absolutely hottest code paths (fwiw we shipped active asserts, including bounds checking asserts in all the PC games I was involved with - carefully monitoring the overhead of course).

The main reason to not use the stdlib isn't so much about squeezing out the last bit of performance, but about control of what actually happens under the hood (and also compilation times). The overall runtime cost of all those active asserts (not just the range checks, everything) was somewhere in the 2..3% range, which is fine when budgeted for upfront.

[Chaosvex]

That's your opinion, others won't agree and would much rather not pay the price at all.

[imtringued]

Those asserts probably saved a lot of development costs and increased the robustness of the software, which is worth a lot more than a few percent on a benchmark.

I personally am more conservative on those things. I'll pick the fastest thing that is reliable.

[bluGill]

Are we talking about games or medical devices here? I expect different things from them. If a medical device needs to turn off bounds checking to get results I'm concerned enough to not want to let anyone use it. If a game can get a slight performance improvement I'm all for it, who cares if it crashes, it is just a game.

[jason_oster]

Screw this game! I lost all of my progress because it crashed and the last auto-save is 10 minutes old. Uninstalled. 0 stars. Getting a refund.

[tarnith]

Who cares if it crashes? The users.

We can all agree it's not medical systems, but audio DSP and game dev both end up rewriting a lot of STL stuff to suit their needs, and often using a restricted subset of modern C++ features for similar reasons.

That isn't some arbitrary choice, but pretty much where everyone continually ends up when solving real-time problems using C++. Whether those be games or not.

[moomin]

The point is that STL does make you pay for stuff you don't need. In complexity and compile times. There's reasons Jai is being developed, and they're not all that Jonathon Blow is weird. As much as C++ owns the game industry right now, it has observable deficits as a great game programming language.

[criddell]

Sometimes there are ways of getting runtime bounds checking.

For example, both of these return the 3rd element of a std::vector:

    auto val1 = vec[3];     // no bounds checking
    auto val2 = vec.at(3);  // bounds checking

[Mond_]

Yes, with the trade-off of essentially requiring exceptions, which are also banned in some codebases.

[samiv]

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]

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]

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.

[demorro]

I find it hard to agree that the stdlib is poorly designed and implemented. In my entire career it has pretty much worked entirely to spec.

Yes, it can exhibit non-optimal performance, and in some specific cases (regex's especially), extremely poor performance, but that's not the same as being poorly designed and implemented, especially given the breadth of the thing.

[lenkite]

C++ stdlib was barely acceptable in the 1990s but is heavily outdated today and suffers from deeply frustrating design flaws.

The ABI Nightmare - The C++ committee has this extraordinarily weird and strict rule: never break the Application Binary Interface (ABI). If a better algorithm or memory layout is discovered, the standard library cannot adopt it because doing so would change object layouts and break existing binaries. The worst part is that this ABI is never defined, so you always HEAVILY pay for what you DON'T use.

std::regex - the Programming Language Joke of the millennium. Even an interpreted language regex engine runs faster.

std::map, std::unordered_map - outdated, badly-designed and slow crap that is beaten even by high-school coders writing map data-structures.

No bounds checking. And Undefined Behavior by Default for operators like std::vector::operator[]

std::iostream - bloated, expensive design, std::vector<bool> - another joke.

Silent Iterator Invalidations causing unpredictable memory corruption.

No deprecation strategy. There are FOUR callable wrappers. At-least, have the courage to say @DEPRECATED.

No Standard Networking.

Missing System Utilities - nothing for process management, standard cryptography, or basic command-line argument parsing, etc.

To be honest, this is just the common complaints - if you run through all the stdlib features, there are dozens of severe problems. Which all the smart people know about, but are forbidden to fix - because of ABI!

[pjmlp]

Which is why one of the security measures in C++26 is to make bounds checking idiomatic, finally.