[flohofwoe]

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

[jibal]

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]

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]

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.

[herr_shield]

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]

What, you rewrote std::deque? Whew!

[spwa4]

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]

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]

Unordered map is a hash map with separate chaining.

[samiv]

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

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

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

[mixolydianagain]

some of the STL is easy to improve on. For example, std::unordered_map performs poorly due to pointer stability requirements in the standard. Most performance sensitive C++ codebases will use something like abseil's hash maps instead.

[spacechild1]

Just a heads-up: if you're already using boost, boost::unordered now has open addressing containers (unordered_flat_map and unordered_flat_map) and they are among the fastest.

[ahartmetz]

Seconding this - boost::unordered_flat_map was only added in December 2022 and many people don't know about it yet.

[variadix]

The STL is not good if you want performance or predictable behavior. The issue is in the specification and the requirements placed on certain algorithms and data structures. It’s easy to beat unordered_map for example with an open addressing hash map, small vector optimization can’t be implemented in vector due to standard requirements, etc.

[VoidWarranty]

Which is worse? std's mess or one you control? I'd take any random game engine's STL over std any day.

[leonidasrup]

C+ Standard Template Library is the best designed part of C++ library. It was designed by Alexander Stepanov.

https://en.wikipedia.org/wiki/Alexander_Stepanov

[tialaramex]

So, a few things (aside from the whole nomenclature argument already in another reply)

1. Stepanov's generic programming is a good idea. Every language you've seen with "generics" that's his idea, to the extent "The STL" is generic programming, everybody agreed it's a good idea.

2. But the STL is very old now, so while the idea is good, this is one of the oldest (Stepanov had tried this in other languages before C++) implementations and so other implementations are often better, because they've learned from experience

3. As well as pretty good generic algorithms, the STL also provides a lot of container types (what Rust would call collection types) and these vary not between "excellent" and "mediocre" but between "mediocre" and "inexplicably terrifying". The most charitable explanation is that they're just intended for teaching. If you teach DS&A to a Computer Science class you want the Extrusive Doubly Linked List to teach in class. If you write software you almost certainly never need this type, but it's front an centre in the C++ STL.

There's a single "I guess I would use this" container type, std::vector. It has an insane special case for bool, because WG21 are idiots, but it's otherwise a good enough growable array type and it's not worth building your own instead given the constraints.

Everything else is silly, or bad, or both. std::unordered_map feels like a hash table I made in class in the mid 1990s, but it's actually the provided standard hash table container in C++ 11 onwards. std::list is just that extrusive linked list for some insane reason. The Microsoft standard library maintainer STL could not offer me any justification for what std::deque is actually supposed to be for.

[bernds74]

I would argue that even the basic concept behind STL is misguided. The rationale I often see is "you only need N algorithms for M container type, instead of N*M". This ignores the fact that algorithms and data structures are not independent of each other, and also that most of the time these days you're operating on vectors, so M ~= 1.

Case in point: list::sort. You don't want to try running quicksort on a linked list. Or remove_if: great we've abstracted the difficult task of removing things without erasing them, except we can't do it on maps. (C++20 seems to add an erase_if, apparently admitting that the two-step remove/erase is silly).

Then there's the fact that C++ iterators are basically pointers into the data structure, where for vectors (your common case) you'd do much better with index/container pairs, both for stability and bounds checking.

[SJC_Hacker]

List::sort is present exactly for this reason

STD::sort only works on a random access iterator, it won’t even compile if you try it on a list

[einpoklum]

> There's a single "I guess I would use this" container type, std::vector.

About that one... I would claim that in a majority of cases where an std::vector is used, what the author really wanted was a similar type, but whose size and capacity are fixed on construction and never change. The standard C++ library does not offer such a type - so people use vector because it's handy.

Agree with your takes on most of the containers. I also dislike how optionals are never used with containers as they were standardized later (and even then, problematically w.r.t. references). Thus, for example, if I lookup an object in a map of T's, the result should IMNSHO be an optional reference to a T.

[Joker_vD]

> a similar type, but whose size and capacity are fixed on construction and never change.

There is std::array for that. Also, for a type with fixed capacity but variable (up to that capacity) size, we're getting std::inplace_vector soon™.

[einpoklum]

std::array requires the size to be set at compile-time, while I was talking about arrays whose size is determined at construction-time. Of course std::array is also quite the useful class :-)

[afdbcreid]

What operations could such frozen vector offer that std::vector does not? If there are none, it doesn't need a separate data structure.

[einpoklum]

Oh, on the contrary, the separate structure is needed and useful because it offers _less_, not more:

* APIs/function signatures explain more clearly what are the intended uses of the structure that's passed.

* More potential for compiler optimization

* Some potential for having these on the stack (if the compiler deduces the size already at compile-time)

* More convenient for static analysis

* No plethora of confusing constructors (including the infernal two-element ctors which can be misinterpreted super-easily)

etc.

[quuxplusone]

The reason I'd want "frozen-size vector" is to replace pairs of data members of the form `T* foos; size_t foos_len;` without paying another 8 bytes to store a useless capacity that's never going to change.

But I don't think that makes such a container worth adding to the STL. So far, it hasn't even been worth writing in our own code. But that's the reason I've thought about writing it.

[ahartmetz]

AFAIK, std::map is also OK for what it is: an ordered, node-based (tree) map. These are (almost) always slower than hash tables. Of course, std::unordered_map, the std hash table, sucks because of unforced errors. For that, there is boost::unordered_flat_map.

[tialaramex]

std::map will be a Red Black Tree, as with most of the other container types this really likes pointer chasing

Unlike in std::unordered_map you are getting some value here, the RB tree is able to achieve meaningful efficiency gains from its use of pointers. The trouble is that your computer isn't a PDP-11, a hybrid which does fewer dereferences but has more locality will trade well here on a real computer built this century.

So, I'm torn, it's not awful but it's a problem that std::map is basically obliged to be a Red Black Tree even though that's not a good fit for today's machines.

[einpoklum]

It has some very useful principles, but also some super-annoying gaffes and mis-design aspects. One example: Allocators. What a mess! Or the fact that if a map lookup fails, an exception is thrown. I can't count the times I've had some app just bail out on me with an at() exception, because the author neglected to handle it (and the map/unordered map interface did not force them to). That does not detract from Stepanov's important work.

[ahartmetz]

The kind of programmer who don't check (or think through so that they can't fail) their map lookups is also the kind of programmer who don't bother with const. What a non-const unchecked map lookup gives you is a default-constructed value that has just been inserted for the only reason that operator[] returns a reference, which must "point" to something. That's bad and can be confusing, but it doesn't crash.

I see that problem much more often than crashes due to unchecked map lookups in production, which are very rare for me. Less than once a year.

[pjmlp]

Nowadays also used by many of us (wrongly) to refer to the overall C++ standard library, instead of what was inherited from C.

[Chaosvex]

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]

The article might be slop, but the problems described in it are definitely real ;)

[Chaosvex]

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]

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.

[domenicd]

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.

[Chaosvex]

Yet they spend a lot of time complaining about features that were deprecated or removed.

[zabzonk]

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.

[bregma]

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.

[johannes1234321]

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.