The tooling people have - as of about a year ago said they are ready. Now everyone who considers themselves early adopters is using then. Most are waiting for the early adopters to figure out what the best practices are so we don't make a mess

YC startup. Toolchain was Clang and sh.

Chromium is gonna be more conservative than that for sure.

That's a shame! It's a lovely language.

I enjoy the syntax and the defaults he picked, and it matches the way I use C++. I prefer it to all the C/C++ alternatives.

It was a new feature. Over 30 years ago now. Template metaprogramming was even featured in the ARM.

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.

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.

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.

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.

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

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.

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.

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.

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

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

Thank you for the advice. I'll think about it. Or maybe just remove the price altogether.

Sort specifically is kind of a weird example, but C++ is full of awful naming.

std::map (which is not a hash map, which is what most people would expect), std::move (which doesn't move), std::vector (which is not a vector), and std::vector<bool> (which is not even a std::vector).

Sure, both languages offer both generic comparison sorts†. But the defaults matter and as always in C++ the defaults are wrong, here it's reflected in naming.

That's not actionable information, except in the sense that the correct action is "don't use C++". Because sure, I know about sort stability, and I know about pointer provenance, and about memory ordering, but there might be any number of things I do not know and unfortunately in C++ "you should know and understand" absolutely everything at all times, which is not viable.

† The C++ standard library sorts are both much slower than in Rust, but hey, they're also both less safe so you're really getting the worst of both worlds

There are two kinds of programming languages: the kind everyone complains about and the kind nobody uses.

Python, Java, Lua, Ruby are ~30 years old, Ada being as old as C++.

Sure, none is perfect and they have cruft and warts, but they are not such a mess as C++ is.

Working occasionally with modern Python helped me love and respect C++ even more.

Python3 is what, 15 years old?

And that's the usual fallacy (just ignore the bad stuff).

But if you work with C++ in professional context, you will encounter it somewhere (library, teamate's PR, legacy code, LLM output, book / blog / conference ...). |

You actually need to know the bad stuff to be able to judge it and discard it.