Ken Thompson's criticism of C++ as incoherent, complex and garbage heap of ideas still resonates with me; C++98 was the last version I used for work although I've dabbled in 11/17/20 out of curiosity.
IMO, if c++/cfront didn't ride on the tails of c, I'm skeptical it would've seen widespread use, but then, that's its main identity which limited it in ways that C++ was not willing to change; It is highly irritating to spend as much time to sanitize the implementation with Coverity/Valgrind and the ilk when the compiler could've handled it.
With C++98, Bjarne's book on c++ internals could've give you good insight into what went on, but later it turned into a whole cottage industry of "effective, more effective, proficient, performant, c++" series of books -- so kiss goodbye to any notion of being able comprehend existing code that's not written by you (until llms arrived). I'm happy to have spent time to learn problem domain instead.
I'll still watch the documentary since it has some of my favorite folks (Kernighan, Stepanov).
> if c++/cfront didn't ride on the tails of c, I'm skeptical it would've seen widespread use
What launched C++ into success was Zortech C++. At the time, 90% of programming was done on MS-DOS. Cfront was nearly unusable on DOS, because:
1. agonizingly slow to compile
2. no support for near/far pointers, which was essential for non-trivial apps
Zortech C++ fixed those problems, and sold like wildfire. This provided critical mass for C++ to succeed. The traffic on comp.lang.c++ angled sharply upward. Borland saw our sales, and abandoned their OOP language product and did Turbo C++ instead. Microsoft saw Borland's success and then did their own C++.
We sold a lot of Zortech C++ compilers to Microsoft. They used it to develop COM.
I heard rumors that Microsoft was developing their own OOP C, called C*. I've never been able to confirm it, though.
Your perspective on this may be distorted due to your personal involvement. Do you believe MSVC++ or Turbo C++ would still have existed without Zortech C++ arriving first? Because if so then I don't think you can really take credit for C++ popularity on the PC.
> Do you believe MSVC++ or Turbo C++ would still have existed without Zortech C++ arriving first?
Nope. As I mentioned, Borland was working on their own OOP C language. ZTC++'s success caused them to abandon it and do Turbo C++. I know this because of my conversations with Eugene Wang. And Turbo C++'s success caused Microsoft to do MSVC++, which was quite late to the game.
Before C++, the newsgroup traffic on C++ and ObjC was about the same. The C++ traffic took off after ZTC++ was released.
Little known fact - when I was contemplating enhancing Zortech C into C++, I was concerned about AT&T's intellectual property. I contacted Ryan Williams (I think that was his name), AT&T's IP lawyer. I asked him:
1. do I need a license to create a C++ compiler?
2. do I need to call it something other than C++?
He laughed and said, no, I could do whatever I wanted. He also thanked me for being the only compiler guy to ask permission.
I read about his passing a few years ago. He was a solid guy.
Something that not many people consider. It is almost certain that C++ "saved" C by existing. Without C++ there would be an enormous pressure to add more features to C itself. One reason why C committee could get away without adding much over the years was that they could nod towards C++ and say "that's their job, not ours". And if later didn't exist who knows what kind of language C would become. Classes? Templates? Lambdas? We can only speculate.
I don't know if this is true. In the 80s there were many languages that were C with additional features or C preprocessors that added and experimented with features similar to cfront. You had OOPC (object-oriented pre-compiler), Objective-C, C*, Concurrent-C. People were experimenting in all kinds of ways by taking C and trying things out with it.
I think it is absolutely true, because adding features to an experimental language that has no tools or ecosystem surrounding it does nothing and people know that.
Niche experiments having features doesn't accomplish anything, but adding just one more feature to C seems plausible.
With C++ people could point people to another production ready language compatible with C that people could use, so there was somewhere they could do and an example of the feature working instead of someone promising silver bullets in theory.
Yeah, OPs claim feels disconnected from C’s identity. C stayed conservative because the areas where it excels (to this day) benefit from its “portable assembler” design history. A history with no C++ wouldn’t have changed that, instead another (either non-C extended or alternative C-adapted [Obj-C, for instance]) language would have taken the market C++ did; likely with a larger runway time due to the lack of interoperability/superset compilation.
Hilarious coming from the guy whose shitty Multics ripoff directly inspired "Worse is Better"
From the essay:
"Unix and C are the ultimate computer viruses.
A further benefit of the worse-is-better philosophy is that the programmer is conditioned to sacrifice some safety, convenience, and hassle to get good performance and modest resource use. Programs written using the New Jersey approach will work well both in small machines and large ones, and the code will be portable because it is written on top of a virus.
It is important to remember that the initial virus has to be basically good. If so, the viral spread is assured as long as it is portable. Once the virus has spread, there will be pressure to improve it, possibly by increasing its functionality closer to 90%, but users have already been conditioned to accept worse than the right thing. Therefore, the worse-is-better software first will gain acceptance, second will condition its users to expect less, and third will be improved to a point that is almost the right thing. In concrete terms, even though Lisp compilers in 1987 were about as good as C compilers, there are many more compiler experts who want to make C compilers better than want to make Lisp compilers better.
The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++."
I highly respect the Ken Thompson and the rest of the old UNIX hands, but wouldn't they admit that the real world is messy and the best solutions in isolation don't always win?
Their creation C and UNIX won over the more advanced LISP and Smalltalk systems because they were simpler to implement. Even their own more advanced Plan 9 based OSs could not displace the more widespread unix-like systems.
It seems distribution and 'good enough' to rely on always wins. IMO, dynamic languages like Perl, Python, Ruby, JavaScript, PHP and the heavily marketed Java provided good enough high level facilities that have prevented people from reaching for Lisp and Smalltalk.
Looking at it through this lens, perhaps C++ was the vehicle for strapping some high level facilities on a widely adopted low level performant language that made it just good enough of a technology for wide adoption.
You think that LISP and Smalltalk aren't widely used is because they weren't easy to implement in the late 1980's? There have been many languages that have risen to prominence in the 40 years since, yet LISP and Smalltalk remain niche languages.
My opinion is that Lisp and Smalltalk are too pure and abstract. C is heavily tied to the real world of computing and can be easier to grasp for beginner. But try to explain variable bindings (instead of assignment) or message passing (instead of function calls) to a beginner in programming. It’s not that they’re hard to explain or understand, they’re just hard to be completely grasped without a foundation in computer science. They’re too alien.
Rust, Python, Java, Ruby, Scala, Swift to start with. These are languages with very wide adoption. Objective-C is very Smalltalk-like, but it is being phased out for Swift.
It's why I've found Rust a joy - enough had happened in programming languages, that it was able to reinvent C++ with some of the best parts of the Haskell/ML/Scala family, some of the ergonomics of Python/nodejs, and bringing the borrow checker too.
C++ is this weird amalgam of like 7 different generations of languages.
But by far the worst part is the developer hostility behind the idea of UB. "Oh, this is not an error, it will compile, we will just secretly stab you in the back."
You can get good and avoid it, and there are tools to help you, but why is that at all a reasonable stance for the definition of a language?
Saying this about Rust and C++ is like saying the kitchen you just built is cleaner than the old kitchen you used for 50 years. Get back to me in another few years.
Now for Rust I don’t think it is going to change a lot. Because it is based on ML, it has the best foundations and all features are known. The question is more how much Haskell vs script/imperative do you want your language to be, and what’s the purpose of the language rather than we had the wrong paradigm and found a new better one. For Rust 99% of its features are known and most are already implemented.
Maybe things around the borrow checker, and await, but beyond that nothing as much as what C++ saw in its history. Even more when for instance you see the article from the guy doing Gleam where traits (impl) are not necessary, all you need is data and function to have the same functionality. Or how ML have been the main factor to most new languages or new features to existing languages.
The future is ML, with languages dedicated to specific use cases and niches. And also ML languages easily readable by AI.
> IMO, if c++/cfront didn't ride on the tails of c, I'm skeptical it would've seen widespread use
Obviously. C++ was a "better C" in that you could keep a lot of your "legacy" C code while improving your codebase piecemeal with C++ features. Your management didn't even have to care, in that C/C++ was accepted as a valid descriptor even by people who should have known better. It's a wonder Java/C# and Perl/PHP never caught on.
> kiss goodbye to any notion of being able comprehend existing code that's not written by you (until llms arrived).
In my experience it takes a while (<=3 months) for folks to become proficient when they see an alien dialect of c++. That may sound totally unacceptable to you (fair). Cpp is also a “big tent” language in that it is genuinely multi-paradigm.
I think LLM’s might help, but sometime they hurt too (confidently/persuasively wrong analyses). The gain is large for small/trivial contributions. For changes that require genuine understanding, I’m not sure (large error bars personally as to whether the sign is even positive).
The last one from Scott Meyers was the final nail in the coffin for me. The chapter about auto and template parameter deduction specifically. Since then, I've been happy with Golang and Java.
Since I've been working in C++ a lot recently I decided to watch the video as I waited for a build to complete. So the length is about right. And fortunately, the video is a delight!
Yes, although in all honesty the actual compilation is somewhat small compared to the many layers of unit, simulation, integration, and regression tests. All those corner cases take a long time to explore.
Personal opinion: C++ is the most elegant language I have used (for about 15 years). If you are the 'systemizer' type and like to have an extremely precise mental model of the thing you write down to the last bit, nothing beats C++. I acknowledge the limitations and uncertainties that come from compilers etc, but still
An elegant language is one that achieves a lot with very little. Forth and Scheme are elegant languages. You're free to like working in C++, and you can sure achieve a lot with it, but I don't think it's controversial to say that it does not do so with very little.
It's easy to make a minimal language that can technically do everything via Turing completeness. That can look elegant until you start writing reptitive or hard to read code with it. Golang "if err" is a classic.
The notion of Turing completeness isn't relevant here, it encompasses almost none of the interesting distinctions between programming languages in practice. And yes, simplicity alone isn't what matters here, or else we'd all be applauding Brainfuck. What matters is strength:weight ratio, or the interesting expressiveness and abstractive power of your language weighed against its surface area.
Makes sense. This appears to be also a symptom of whatever you work on most (or start with), your brain starts to absorb that into its way of thinking.
I very much prefer to work in Rust but it does force you to design things in an counter-intuitive way in certain situations (linked lists for the canonical example). Specially for lower level software I find C or C++ to allow for much more flexibility and thus the most straightforward design possible.
I really don't think Rust does, but that's if you're outright refusing to use `unsafe` anywhere. Might be a little noisier if you're using things like ManuallyDropped instead of just using raw pointers, but the language doesn't stop you from doing things in ways you would with C or C++, it encourages you to encapsulate the hard parts so you can worry less about correctness of 98% of your codebase, instead of fearing incorrect behaviors can silently sneak in.
That's absolutely correct. Wild to see it downvoted without explanation, while you preemptively mentioned the tradeoff that you do need to worry about correctness in that case (just as much as in C/C++), but that only applies to a small part of your codebase, so it's still a huge benefit.
The only downside is that unsafe rust is more verbose than C/C++.
So happy to see Andrei Alexandrescu was included in this documentary. His book on modern C++ design was a mind opener at the time I read it. Maybe still is today. Anybody else read it?
It still amuses me, but Andrei's books were the "last straw" that pushed me away from C++ for many years. Great books, truly, and they helped cement the notion that I wanted to move on to a different language. (Go, at the time.)
I seriously hated the book, too. The title should have been "Cute template tricks to make you feel smart and increase compile time, when to use: approximately never". I think about two things from the book caught on, one of them how to deal with lists of template arguments pre C++11. It's kind of horrible, but was sometimes (more or less) necessary.
Yes, I feel the same way. I met Andrei once on a Meetup in Munich, basically telling him that he taught me how to think which led to a somewhat awkward conversion. Fun times nonetheless :-)
I read it recently. I liked a few of the chapters especially how policy classes fix some issues with OO design. I do recommend asking an AI chatbot to summarize each chapter and say what the modern equivalent is since some of the idioms have improved. I think one whole section was obsoleted through the use of std::variant and std::visit.
It also caused developers to produce template-heavy code that took minutes to compile. We used to joke that these developers were "bitten by Alexandrescu".
But it was indeed a nice book that really made stataic polymorphism popular. Before that, most books focused on building object hierarchies with virtual functions, etc.
Many browser rendering engines are built in C++, so C++ is parsing the HTML. My general point is that many web/internet techs that web devs interact with have C++ one abstraction level below for actual implementation.
A C++ compiler outputs machine code that runs on a raw cpu if you want it to.
The os providing a virtual cpu is just an optional extra and so irrelevant.
That is not true for someone writing php or js or anything that runs in an interpreter. C/OS/Kernel are not actually the interpreter for C++, or they are, but only in the same way that the bare hardware is. C++ is the final interpeter layer besides assembly.
He has a point. The video certainly feels more like a hagiography and I noticed the lack of critical voices. Only in the last 10 minutes they touched on some common criticisms, like the growing complexity and the memory safety issues. I still enjoyed it, though.
It's surprising that C++'s development trend continues.
When a game or program is made with C++, it's usually nice because performance is mostly guaranteed. But if someone told me to write C++ myself, I'd cry. There's too much to memorize, and the standards are too varied. When I go to a project site for maintenance and it's a C++ project, I instantly lose energy — because it's just too difficult.
I'd be happy if someone else wrote it, but it's not a language I want to write myself
Personally I don't find programming with C++ that hard. The downside is it needs a brain warm-up, and this is per project, but once that flywheel is spinning, I find it almost effortless to write code.
I have to go through the same warm-up more or less for any language I work with, so it's not that different than writing Python, Go or Java for me.
I find C++ not hard at all when working with familiar idioms, restrictions and toolings (familiar to me). But it's hard jumping into new codebases and adjusting yourself to new patterns. Recently I did a lot of programming using C++23 Modules and it was a breeze.
There's basically dozens of very nice languages inside C++. That can be a blessing or a curse.
I'm anxious for Herb Sutter's CPP2/CPPFront to become a standard.
What type of project actually uses C++ 23 modules in real life? What kind of toolchain enables that? When I worked on Chromium, they were indefinitely in the "maybe in 5-10 years the tooling will be ready" camp.
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
It’s been 6 months but last time I checked neither IntelliSense nor clangd worked with modules. The build tools have been just about functional for a while though, you’re right.
Yeah, Intelisense is a bummer, but you really need VS proper, nor VSCode, which I assume given the clangd reference.
Whereas one kind of works (VS), there is apparently no work going on VSCode Intelisense, ticket is stalled since January, and the promised announcement never came up.
We are now getting close to the distance between c++03 and C++11 for making basic modules work on main line toolchains and build systems. That’s absolutely wild.
It may not be an abstraction of a real machine. But the C abstract machine is very close to the foundational idea of how a computer work. And it’s quite easy to bootstrap.
Importantly my work involves me often being able to look at C and think about the assembly and back and I regularly work on ESP32, ch42(riscv) and atmega avr8.
I couldn't do that with mciropython on any platform.
they're technically not wrong. C is literally an "abstraction" of the machine. As we know, the whole point of an abstraction is to ignore the multitude of details :-)
There are so many standards and idioms that it gets confusing. There are still legacy codebases out there — some codebase still use C++98 as their standard, others use C++11... And with Unreal Engine, the modern C++ standard is C++14, right? There are things like smart pointers, but some places don't even use them. I feel like there are just too many features. When I saw template metaprogramming — that new feature — I realized I have no talent for C++.
I have developed things with C++98, C++11 and C++14. Every of these standards are so vast, so remembering everything (even in a single standard) is not possible. Instead of knowing everything, I first fix the standard I want or need to work with.
Then I design the thing I want to build. I always design what I want to build beforehand. This takes a couple of iterations from high level to low-ish level. That last design becomes a bit language dependent. Then I select some of the core tools that I'm going to use (which kind of pointers, classes or structs, etc.)
With that design in mind, I go "library shopping" both for file formats (if any) or other stuff like vectors, etc.
Armed with the reference docs of these, I write my code with the toolbelt I have built for the project.
Some things are hard, but they are not impossible. I find thinking like compiler helps a lot.
This is true of any language. Python with flask vs django, with/without type hints. JavaScript with anhular and vue.
The varying standards are no different to major python versions or go versions - arguably there’s even less between most versions than there is in your average go release.
The differences in apps and frameworks don’t matter for day to day - std::string, Unreal’s FString and QT’s QString all are similar enough that 99.9% of the time.
Metaprogramming is one of those things; you either write it or you don’t. Knowing some basics is required but the vast majority of people use a handful of pre existing things without understanding the nuances of how it works under the hood.
Is it? Java has changed a lot, but in such a way that it's still easy to mentally map new features to the old ones, provided you have understood the core language. IDEs can even convert your code from old to new and back.
Still true for C++. Can still mentally map new features to the core language C. A modern Cfront transpiler can still be written.
Template meta-programming maps to C pre-processor macros. The sad part with both is generated code cannot be examined thus the unreadable compiler errors and slower compilation as it's regenerated every time.
Slightly off-topic: Rust can also be mentally mapped to C.
Yeah it is! Java 25 changed constructor behaviour to allow logic to run before the calls to super(). That’s an enormous change.
On the c++ side, “modern” features like span, smart pointers, range based for loops, format are all really simple to reason back to for anyone who is a programmer. Stuff like modules and concepts is a bit different, but most people aren’t in the innards of those every day, in the same way that the change in header size doesn’t affect every single Java developers code, but you should know about it.
> When I saw template metaprogramming — that new feature — I realized I have no talent for C++.
It's not a new feature. And tbh, compared to Typescript, C++ templates are tame ;)
(but yeah, deciding when to stop digging into the template metaprogramming rabbit hole requires some common sense and sanity, too much template complexity is almost never worth the hassle)
When I went on a business trip for screen golf program project back then, it was UE4(CPP14), By your introduction UE5 onward, it's 20. I've updated my knowledge.
I have felt this many times. However, the effort involved in writing code does not indicate the amount of issues that code may have. This is why I prefer Rust to C++ these days - it just removes 90% of the development tail, which can be quite long in C++.
That’s true, however I tend to build my testing harnesses alongside the code I write, hence every single function and the whole flow has a testing suite ready almost immediately (via Catch2 99%of the time), and every commit is tested locally and by a couple of runners after the commit.
This coupled with generous amount of Valgrind testing allows me to catch problems early and fix them immediately. Doing this allowed me to write very performant code without any leaks or accuracy problems.
Another thing I do is making some cases mathematically impossible. If this promise is broken, code is guaranteed to crash at that point, so it’s self verifying in a sense.
Of course enforcement of this is possible due to fact that I code solo most of the time, and has the discipline to do boring things as well as the exciting and fun things.
The difference, if you split hairs, that the brain warm-up takes a bit longer. Maybe a couple of hours, or a day at most.
Otherwise it's not different for me. I don't feel different while writing with any other language. I guess the main reason is I always think like the computer first and translate that thinking to the programming language at hand.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
You can prevent more than enough crashes with enough testing to make gamers happy. Even if you prove there is not out of bounds error I still want a medical device to check
Even with an extreme high level of inhouse testing (which is needed anyway) you'll never find the bugs that are discovered when a hundred-thousand gamers try to exploit every little feature of your game.
The reason to keep asserts in release mode is so that when one of those asserts is triggered "out in the wild" the bug investigation is dramatically simplified. The assert message and callstack is usually enough to figure out what went wrong. With a regular crash that happens without asserts the actual reason of the crash may already be obfuscated enough that a useful bug diagnosis is no longer possible. E.g. an assert is usually triggered very close to the bug, while crashes are usually only the end result of a whole cascade of events triggered by an initial bug.
Fair, but the counter is eventually you have enough real world testing to have confidence and so you no longer need the assert. If 1 in 10 user's have a crash that is unacceptable. However, what if it's only one in a million, or one in ten billion? At what point can you say, 'it's no longer worth worrying about that rare case.'
And this is why games are different from medical devices. In medical devices, I would worry anyway. In games, especially in a tight loop, it may be that extra CPU instruction is an important difference in performance.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
> 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.
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 :-)
But that's the point. You _can_ push_back, or resize, or reserve, etc. etc. My claim is that the more common use case is the one where this _cannot_ happen.
> If you want to get f cy you can also give it a custam allocator
And then nobody will want to use it, because that's not interchangeable with containers vector with the default allocator, and also difficult to understand. I mean, look at PMR allocators, which are not even that custom. They see very little use I'm afraid.
Well, if you want to, I can write you a forwarder-wrapper around a std::vector that would inhibit allocation-inducing operations. Now, getting it into stdlib, that's a different matter entirely...
Also, do I understand correctly that you want both the capacity and the size fixed, i.e., the container's elements have to be pre-constructed and supplied to the constructor via an initializer list?
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.
This is how I designed my vector in C. Note it is still not frozen as you can use realloc just fine (even with good performance) and/or external tracking of the capacity in tight loops.
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.
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.
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.
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.
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
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.
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.
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.
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.
You're right that C++ has a lot of features. But like mentioned elsewhere most projects define their own conventions and the subset of features that they use.
Also the nice thing about having a large set of features is that C,++ allows you to write very nice abstractions (or not) at both very low or at very high level. In other words you can be very low level with online ASM and bit operations and bit and direct memory manipulation or very high level almost like a script language. Whatever the problem domain needs C++ has got you covered.
You can be pretty productive even with 70% of the language :) It is a common misconception that C++ is suitable only for game engines and similar domains. It is perfectly fine for applications domain as well.
As a side note, regarding your profile info, unless you are based in North Korea, please at least add one 0 to your rate. You'll get more long-term and high-quality clientele.
> You can be pretty productive even with 70% of the language
Or even far less than that. I like to use it as C with lambdas and namespaces. Sprinkle in metaprogramming as needed. Even just not having to remember to call cleanup code thanks to dtors would alone be enough to sell me on it.
I once wrote a pure C project years back that made heavy use of complex numbers and 2D/3D vector math. At one point I got so fed up debugging my expressions under an endless parentheses-hell of `vadd(vmul(vadd(...), vadd(vmul(...))))` that I threw my hands up and changed the file extensions to .cpp just to use std::complex<T> and enough operator overloading to type vector expressions like a human being.
Honestly, I don't expect to find clients here. Fundamentally, you have to trust me to give me work. The amount of money doesn't really matter much to me.
One of my hobbies is rummaging around thrift stores appreciating tacky things from bygone eras, sifting through ill-conceived modern junk, and delighting in simple, solid tools where I can find them.
> There's too much to memorize, and the standards are too varied. When I go to a project site for maintenance and it's a C++ project, I instantly lose energy — because it's just too difficult.
I've been feeling this way about web dev for a while now, and sometimes look at C++ devs with jealousy, wishing that the crazy amount of memorization/varied standards/rough maintenance/high difficulty I experience were only limited to the language that I write.
I don't really understand this perspective. You don't need to memorize anything to learn a new programming language. You choose a medium-sized project you've already done in another language, start with "Hello world," and add one line of code at a time until the project is done. When there's something you need that you don't know how to do, you look it up.
You'll end up with a strong understanding of the subset of the language that's actually useful for the thing you want to build.
You get used to writing C++, just like you get used to writing any language. I've been writing C++ for quite some time already, on a daily basis, and it became second nature. Though I remember how much of a pain it was when I initially move into it
>There's too much to memorize, and the standards are too varied. When I go to a project site for maintenance and it's a C++ project, I instantly lose energy — because it's just too difficult.
If you'd already been using it for 10+ years you wouldn't feel that way, because you'd already have memorized a lot of it.
You don't have to use them. There's a handful of nice to haves in modern releases but its totally fine and sane to just ignore whatever the committee is distracted by at the moment.
Hell, if you wait long enough, they'll just deprecate it before you can care to bother.
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.
Im talking about your own personal coding. You dont have to use the new things. You dont have to know them to decide to discard them. In fact, the criteria to discard something is to not know it. You generally shouldn't be using things you dont know anyway.
The fact that other people use things you do not know is not a reason to stress out about the dumb pace and direction c++ is moving in. It is possible to enjoy a life free from fomo about the c++ standards goalposts.
> But if someone told me to write C++ myself, I'd cry. There's too much to memorize, and the standards are too varied
If someone tells you to write a web app, do you also cry? Surely there's more JavaScript frameworks than subsets of C++ at this point, no? Do you also go memorize all of them? Or do you just quickly pick one, and then only learn that one, and forget the rest exist? Because that's kinda how you approach C++. You pick a subset (like, say, just modern C++, only caring about C++17 & later or whatever), and just use that. And move on with your life. There's absolutely no reason to learn how std::auto_ptr works because it's dead in the same way you aren't learning how PHP & CGI works if you're making a modern web app. They're dead relics of the past that you can just pretend don't exist.
Not really, despite all its warts, it is exactly because of them that many reach out to C++.
Many of us don't like C, it was already too little and too unsafe, when the first C++ compilers started to hit the market in early 1990's, hence why all desktop OSes moved into C++ for their frameworks.
The return to C has caused by the rise of FOSS, UNIX winning the server room, and early GNU coding standards to use only C as main compiled language.
Additionally as many other programming language ecosystems have discovered, it is easy to beat C++ in version 1.0, and eventually all of them grow to get the complexity of their own.
I reach for C++, because the language runtimes, compiler tooling, and GPGPU frameworks I care about are partially written in C++, and I am not in the place to be writing new ecosystems myself.
I work maintaining the toolchain and language runtimes for a commercial safety-certified embedded operating system. I am deeply familiar with C and C++ because I live it and breathe it every day and have done so for over 40 years.
Most of our customers use C, probably for historic reasons but also because it is much much easier to reason about and that becomes very important when auditing for functional safety certification. If someone's life depends on your software, you really want to be able to reason about its correctness because orange jumpsuits enhance no one's complexion.
Many of customers are now using C++. From the problems they have reported, well, they just shouldn't. It's not that it is a bad language (it isn't) or that it is inherently unsafe (it really isn't: exceptions are safer than propagating return values as long as you use them in exception conditions, because not catching one will return you to a designed safe state very quickly, and RAII is the best thing since sliced cheese). It's that cutting and pasting from Stack Overflow, and now vibe coding, makes for massive codebases that are next to impossible to reason about. I now see a lot of problems from customers where my first reaction is "don't write code like that" and "you can write bad JavaScript code in any language, can't you?". While it butters my bread and I enjoy the language, I really recommend against using C++ for safety-certified embedded software. Stick to C.
If only C actually had fat pointers as Dennis Ritchie, one of the authors, proposed to WG14.
It is quite relevant to note that the C authors, were keen to explore Alef as alternative on Plan 9, and based on the learnings reduced C's role on Inferno, and eventually took part in Go's design.
Even though they were not keen into using C++ (Plan 9 doesn't even support it), they were also aware C wasn't to be used for everything.
Neither Rust nor Zig are appropriate at this time for certified functional safety. Given the definition of the languages is "it does what one particular implementation of its compiler, runtime, and standard library does at this time" it's not possible to construct a workable safety case for their use.
Enthusiam and neat ideas are not sufficient to certify a development tool for functional safety.
I think this hits the nail on the head. All the features of C++ help you write a code which you should have written in a much simpler way in the first place.
(Safe) Rust is a lot better about the "Pit of Success" design than C++
There are fundamental technical choices to deliver that, but also ergonomic things like notice Rust's []::sort is a stable sort, whereas C++ std::sort is an unstable sort. If you don't know about sort stability in Rust what you wrote works and in C++ you get a nasty surprise.
C++ has std::sort() and std::stable_sort(). You should write what you mean, and you should know and understand your tools. Blaming the tool for your ignorance marks you as significantly less than an artisan.
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
> 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.
Why, exactly, is the c++ std::sort "wrong"? There are tradeoffs both ways. You happen to prefer stable sorting to speed, but that is a preference not an objective fact.
It's silently an unstable sort, which is surprising, and then to add insult to injury it's also slower. Yeah, I know, the C++ unstable sort is so slow it's slower than Rust's stable sort.
YMMV for input types, sizes etc but generally that's what the numbers look like and though it's not universal it's actually quite common. "I bet the C++ is faster" is the wrong instinct, sometimes by a large margin.
And stable sorting typically allocates large amounts of memory, which is also an unpleasant surprise.
I prefer the C++ naming convention, because it matches my expectations. When I studied CS, quicksort was considered the default sorting algorithm, and stable sorting was therefore a special case.
My pet peeve is that standard library sorting algorithms are still mostly single-threaded. Multicore CPUs have been the norm for ~20 years, but standard libraries still don't offer reasonable algorithms for sorting large arrays.
No? One of the giveaways of how unserious such responses are is that I spent many years getting paid to write C. The home where I'm writing this was bought† with money made writing C years ago. Rust wasn't even a twinkle in Graydon's eye when I started that job, let alone when I first wrote C last century.
The choice to provide the unstable sort and then add a stable sort as an afterthought smells of the New Jersey approach to me. It was easier to do this, and too bad for the users, they weren't the priority.
It's the wrong choice because if you don't know about sort stability this outcome is surprising, so this means that although a beginner probably thinks they know what "sorting" means they actually mustn't use the sorting APIs in such a language until they've learned extra material.
† For cash, I don't like to owe people money, including having a mortgage
You are failing to make an argument for why stable sorting is objectively the correct choice. Just because something doesn't match your expectations doesn't make it wrong.
There isn't a symmetry here. If you know about sort stability then you can seek out the unstable sort if you know that works for your purpose, if you do not know about sort stability then the unstable sort's behaviour would be astonishing, so stability by default is the right choice.
It's not so simple that you can just declare what is surprising. Surprise depends on context, and not everyone will have the same context as you. You say you would expect the term 'sort' to mean a stable sort, and I would expect it to always mean in-place sorting, others may expect it to use the absolute fastest way to get something sorted... Different users will have different priorities and therefore expectations.
Sort stability does not matter when the sorting key is the only thing in your data being sorted. E.g. When I sort my M&Ms by color, I never keep them in the same order, because it doesn't matter. A red M&M is a red M&M. Nobody expects their red M&Ms to remain in the same order after sorting. I do tend to expect my M&M sorting to happen in-place. I expect to not need to provide additional candy holding bowls to later clean up that were used for temporary storage while my M&Ms were getting sorted. But I'll optionally grab additional bowls when I'm in a time crunch it if it speeds things up...
Now, if we're sorting all the cars on a parking lot by color, it may be more important to keep all the red cars in the same order where they started, for example if they were previously already sorted by brand, it /can/ be useful if that is preserved. But it's not guaranteed to be important or useful. Maybe the rich owner just want to torch all their red cars all together. I typically won't have access to additional temporary parking lots only used during sorting, or maybe the owner is coming with a flame thrower at 1PM and it has to be done as fast as possible whatever the cost. There is a tradeoff, rent additional parking lots during sorting, or take more time and do in-place stable sorting, or jumble up the car brands.
So what I want is control. That's all. Whether or not the ambiguous term 'sort' is stable or unstable, or in-place or not is just semantics. The only way to get clarity is to either use prior agreement, or to not use ambiguous names. Maybe a language should ban 'sort', and only allow 'foo_sort_bar' names with stability of memory usage postfixes or prefixes to 'inform' the developer. Neither choice is ideal and will satisfy everyone. It's like being a DJ at a high school party.
I'm not saying that the STL is great in practice, since it appears to optimize for usage flexibility with defined algorithmic and memory complexity at the big-O level, and mostly disregards actual real-life metrics. Arguing, however, that a language or library is better because an objectively ambiguous choice was made differently than your expectations is like arguing for fundamental superiority of either endianness over the other.
> It's not so simple that you can just declare what is surprising.
On the contrary, of course I can tell you that I was surprised and I'm far from alone. The fact you immediately grasped for "real world" comparisons ought to tell you that you're not thinking about this correctly because these are software sorts and so have very different affordances than the real world.
The claim that you wanted control doesn't make sense in the context of C++. There are in place stable sorts - the bubble sort you may have seen in class years ago is one, but C++ doesn't promise one in its standard library. However it does provide an unstable sort, which it just names "sort" and that's what I'm pointing at as a problem.
As to the "absolute fastest" you're in the wrong place if you've used a generic comparison sort expecting the "absolute fastest". For the machine integers it's usually not even the correct category of sort for "absolute fastest". But the C++ standard library is the wrong place to look even if you did need a generic comparison sort, because so much crap C++ exists and maintainers are scared to change anything for fear of what may happen.
Did you know libc++ didn't even have a guaranteed O(N log N) sort until the Joe Biden presidency? The introsort paper was written last century and the C++ standard itself did finally incorporate this basic requirement in 2011, but it took another decade for the Clang team to fix this.
Ok, I'll keep it short: I'm far from alone being surprised that a sort allocates temporary memory...
C++ is used by a lot of different people with a lot of different background, and... expectations...
My point is that "sort" is ambiguous and having expectations on ambiguity and arguing that a certain one is better is like arguing little endian being better or worse than bit endian.
> Ok, I'll keep it short: I'm far from alone being surprised that a sort allocates temporary memory...
In a sense I'm sure this is true. C++ programmers routinely report being astonished about all sorts of properties of the language they have previously insisted they know well and who could blame them (for the former, at least).
Again, this is not symmetrical. LE and BE are symmetrical, if you have to pick one there isn't a "safe default" that isn't surprising to people who expected the other one†. In contrast sort stability isn't like that, all stable sorts also meet the criteria for an unstable sort. Likewise all the in-place sorts meet the criteria for an allocating sort.
C++ chooses to offer an unstable sort just named "sort". It doesn't offer a stable in place sort at all, but it does offer a stable allocating sort and names that stable_sort
† But what you can do is where it matters you explicitly offer the LE and BE options and silently whichever is native on your target is fast. Users can write whichever they meant and their program works rather than "Oops, by default on this platform it's the opposite byte order, there's a special conversion function to run". Needless to say C++ doesn't do this either.
The ecosystem isn't fine - just to get a project going requires picking a non-trivial set of tools and approaches, none of which the C++ standard enforces or guides to.
For example, will you manage dependencies via packages? If so, with what? What will you use for building your project? The list goes on and on.
- new features overlapping old features from previous standards without replacing them or deprecating them (function::copyable_function vs std::function, std::less<> key for transparent lookup in maps)
- new features not usable by the layman (coroutines ...)
- Cryptic syntax (reflection...)
- Stuff you are told not to use because of performance reason and that cant be fixed because of ABI (regex)
- Compile errors that are 1km long (no, concepts are not helping here, the 'nicer' message is still buried into a hot pile of template instantiation callstack).
I wonder how many programming languages would be able to devoid of all or some of these problems when they are 40 years old.
It's easy to compare new and old languages, and saying older languages are wrinkly. Let's see how other shiny programming languages look like when they are 40 years old.
I personally find the lack of native package management in C++ as a blessing. Go, Python, Rust has it, and this always causes pulling in infinite number of packages for any trivial operation.
sudo-rs was pulling in 1M+ LOC as its dependency chain at one point. I believe they removed the biggest offenders, but I didn't check it recently.
C++ needs to die. I get so many people are invested in it and so much code is written in it. I used to be a fan and it's still my main job. But, in 2026 with LLMs able to find all the exploits, and with more and more adversarials, we need a language that is opt-out of safety, not C++ which is opt-in + super vigilance to get safety. It doesn't work and decades of experience proves it.
C++ was a superb language for its time. There was nothing faster with as-powerful abstractions. It showed how far you can change a language too, with C++11 being a massively better language with shared_ptr and company.
It took in almost every idea, and the battlefield showed us which do work and which don't. We get to keep RAII, move vs copy, smart pointers, placement-new, and generics. We get to drop auto_ptr, copy-by-default, its specific exceptions implementation (fight me), multiple virtual inheritance, and templates as full code substitution.
In my opinion the battles have played out, and Rust is the best sum-up of what worked (it even inherited the compile times! Lucky us!)
I love a free documentary about something that I'm passionate about. So many thanks.
However, I'm a my own kind of weird. I cannot watch a documentary that's made out of people saying short sentences. I get that it's made to 'have them tell the story', but I need a narrator to tell me what to think because I get distracted.
I‘m out of the loop: we‘ve had Python, Clojure and possibly something else recently. Is that a series by the same people working through several languages? Is it happenstance? Is it a trend, and every programming language is now scrambling to get their own video documentary?
That‘s cool, since it establishes a brand. If one was done well, the others probably are, too, so even if it‘s not your language of choice, it will be interesting.
I had an idea for a special reminder app I wanted for myself. It's complicated enough that it comes to 9,000+ lines of code. I wanted to write it using the C++ UI library wxWidgets, because I like that wxWidgets uses native widgets, and is cross-platform, and that it's easy to make an app look nice. And that it doesn't use tons of memory.
There's a wxPython library, but I didn't want my UI to be limited due to whatever gaps may exist in that wrapper.
So I had AI write it in C++. Took about a day for me to get it done. It's perfectly solid. It did hit a couple of memory errors when I first used it, but I could give the AI MacOS crash report and the AI fixed the bugs easily, with no other involvement from me. (I compiled in a debug-friendly mode; no downside to that because it was just for me and was plenty fast enough.)
25 years or so ago, I was a fairly good C++ programmer. Haven't touched it since. And that includes this application, which was completely AI-written.
Hey I'm curious on how your reminder app works and to what effects, if you're willing to share. I'm on iteration 3 already of my reminder app, also vibe coded, and it helps me a lot. My first one was inspired on Remind [0].
My only problem with C++ is that it’s too verbose. my eyes need to parse huuge chunks of things when I just want some convenient syntax for it. otherwise the idioms are pretty universal for most programming languages nowadays.
Interesting, I don't find modern C++ verbose at all. 'auto', range-based for-loops and structured bindings did a great job at reducing the verbosity of C++98.
On top of that, C++ allows to design very concise APIs. (One of my favorite examples is sol2: https://github.com/ThePhd/sol2).
Library code involving templates, on the other hand, can be pretty complex and hard to read. Concepts and other C++20 features (like [[no_unique_address]]) are certainly an improvement, but only new projects with no backwards compatibility requirements can actually use them (unconditionally).
C++ is quite amenable to making things less verbose. For example: Instead of a standard library algorithm taking a pair of iterators, you could have a function taking a container and calling the other function with its start() and end(). And then, with newer versions of the language, you can use a ranges-based function. There are lots of such syntactic hacks, from `using` through typed literals all the way to preprocessor macros (which we want to avoid, but are still there).
That's how you emulate language features that aren't there originally. I've "impelemented" a static code block, like in Java:
What a lineup of contributors—Stroustrup, Stepanov, Kernighan, Lattner, and more in one film. Forty years from 'C with Classes' to the fastest-growing of the top four languages is a remarkable arc, and it's nice to see the people behind it get their due. Adding this to the weekend watchlist. Thanks for sharing, Herb!
Romero was a prolific programmer himself back in the day. He's become more known as a designer because Carmack took over as the main engine programmer at id, but Romero was still writing tooling and editors, in addition to doing the level design.
I obviously don’t know them personally, but what I get from this old school generation that have been a pillar of computer science and, why not, modern human history, is just a tiny little bit more humbleness than “influential” people nowadays.
They may be humble in their older age but the good majority of people on the list were known for anything but their humbleness back when C++ was a much more dominant language.
C++ is one of the languages less suited to the strengths of coding agents.
The language which still supports C-style pointers, arbitrary datatype conversions, and inherits architecture-specific undefined behavior gives you too many ways to fail at solving a problem.
As a programmer, I love coding in C++ because I know what I'm doing. I'd hate reviewing C++ code though.
A few reasons:
1. Header files make C++ verbose. Header files are well within LLM's ability
2. LLMs can handle setting up cmake for you
3. C++ is very well documented relative to (most) newer languages
4. LLMs can port modern features like websockets and build API wrappers easily, reducing the disadvantage against web (since most documentation is for JS/python/go)
Coding languages have been developing for speed of (manual) writing - akin to how human languages did with modern alphabets. Now that writing is a lot easier, languages will likely evolve towards a focus on execution (or in the case of human languages, speed of reading and precision of understanding)
All of those seem like barriers that make C++ unappealing in general, but you're deciding to overcome the barriers using an LLM and seeing that as a strength somehow?
Just speculation, but I think we would expect a language to grow if AI is effective with it. C++ has a lot of training data. Most large software projects are written in C++: web browsers, compilers, 3D renderers, game engines, UI toolkits, etc.
AI is also probably more effective with statically typed languages since the compiler catches a wider range of errors.
Reddit's r/cpp has always had some level of "My First X" posts where somebody goes from their first C++ lesson to being confident they've written the "World's Best X" in about a week. The AI slop made this much worse because now the author has been told by ChatGPT or whatever that they're a genius.
All the popular PLs have this problem to some extent.
Herb's blog post links to the SlashData Developer Nation Survey, so presumably that's what the claim is based on. The company has a methodology page here [1], and it looks like the Developer Nation panel [2] is one of the sources used by that company.
Hi, I'm a Principal Market Research Consultant with SlashData. We've been around for more than 15 years, and we work with the largest organisations in tech when it comes our market research on developers (our client page include AWS, Google, Microsoft, LF, Cisco, and so on and so on). Not bragging, but trying to assuage concerns that we are some fly-by-night org that popped up out of nowhere.
The makers of the documentary reached out to us to use our footage in the report and Bjarne has also used our report/blog when talking about the future of C++. In general, our hypothesis about its continued relevance is in line with what the documentary itself reports: developer numbers have grown massively and C++ has a very specific series of use cases that maintain its relevance.
Our methodology page is lengthy, but it can be summarised by the combination of several pieces of distinct information. We have labour statistics from various national governments to provide reference points, we use statistics from areas developers associate with (e.g. StackOverflow or GitHub) and compare against responses from inside the survey, and our own build-up of numbers based on the proportional data from within the survey (region, age, area, development, etc.). We have been doing this for many years. We also acknowledge in our reports that we are confident in all regions, but with greater uncertainty in the Greater China region, as we are a non-Chinese firm, so we have to work with partners in the region which minimises our confidence in the region.
The report lists the numbers for the major leading languages, basically any language that is used in multiple areas of development and has more than 500k users, give or take. It is not a perfect measure approach but it is about giving the most useful information at the highest level. We also exclude things like SQL because they are nor programming languages, unlike most of the other measures.
For the report, we typically have blogs available with similar information, but our free reports are designed for lead generation, which is why emails are asked for.
I have the utmost respect for Casey, but his disdain for Stroustrup is unfounded. The fact of the matter is C++ occupied a niche in the right place and at the right time, and it grew from there. Many mistakes have been made, but Stroustrup is in no way personally responsible for all of them and I don't think Stroustrup is a bad programmer (something I've heard Casey say in some of his videos). You can argue that the committee route is not the best, but C++ is here to stay and by some metrics adoption is actually growing.
I agree. His negativity has probably detracted quite a few people from him that otherwise are quite aligned. Still, his historical remark is rather peculiar.
As for the language, yes, sadly, it’s with us seemingly to stay. I code it professionally and I can’t find a single interesting, or even good, thing about it. Apart from wide adoption of course. Everything about it feels extremely badly designed from the user perspective (though it’s probably technically very impressive) with many details, that probably the sanest strategy is to use a small subset of the language. At least I don’t have to use STL at work, that’s something positive, I guess :)
Strangely, I've never seen any nice code from Casey despite all of the mud slinging he's done over the years. Maybe it exists somewhere but I watched a lot of Handmade Hero when it was starting off and the code was a mess.
It feels as though he just attracted an audience of junior developers who take everything he says as gospel, as is often the case with social media programmers. Lord knows I've argued with some of them and they usually crumble as soon as they don't have one of his opinions to throw back at you.
I'm confused. I looked at the Handmade Hero videos and I had no trouble following - it was simple straightforward procedural code.
As I understand it, his code does "exist somewhere". Bink 2 from RAD Game Tools, which seems to ship with practically all games.
He also developed the Walk System that shipped in "The Witness" (2016). You can see his blog posts and video lecture about that. I see that he and a Jay Stelly from Valve simplified the GJK algorithm, and he talks about how to implement it.
I know he has his Performance-Aware Programming series, where he talks about the technical details of hardware and how they relate to code performance.
Here, I even found a tweet listing all the things he'd written till that point: <https://xcancel.com/cmuratori/status/1412839131063873536>.
Perhaps you didn't look hard enough?
Can someone give me links to Bjarne Stroustrup's code? I tried searching but I'm having a hard time finding anything. I would like to verify some of the claims being made in the other comments (it's hard to tell if someone's code is better or worse relative to another person's without having access to the code and comparing important metrics and all that.)
Casey also got less aggressive when talking about Stroupstrup lately, especially after his last talk at Better software conference, where he mentioned him multiple times with a lot more historical context.
Ken Thompson's criticism of C++ as incoherent, complex and garbage heap of ideas still resonates with me; C++98 was the last version I used for work although I've dabbled in 11/17/20 out of curiosity.
IMO, if c++/cfront didn't ride on the tails of c, I'm skeptical it would've seen widespread use, but then, that's its main identity which limited it in ways that C++ was not willing to change; It is highly irritating to spend as much time to sanitize the implementation with Coverity/Valgrind and the ilk when the compiler could've handled it.
With C++98, Bjarne's book on c++ internals could've give you good insight into what went on, but later it turned into a whole cottage industry of "effective, more effective, proficient, performant, c++" series of books -- so kiss goodbye to any notion of being able comprehend existing code that's not written by you (until llms arrived). I'm happy to have spent time to learn problem domain instead.
I'll still watch the documentary since it has some of my favorite folks (Kernighan, Stepanov).
> if c++/cfront didn't ride on the tails of c, I'm skeptical it would've seen widespread use
What launched C++ into success was Zortech C++. At the time, 90% of programming was done on MS-DOS. Cfront was nearly unusable on DOS, because:
1. agonizingly slow to compile
2. no support for near/far pointers, which was essential for non-trivial apps
Zortech C++ fixed those problems, and sold like wildfire. This provided critical mass for C++ to succeed. The traffic on comp.lang.c++ angled sharply upward. Borland saw our sales, and abandoned their OOP language product and did Turbo C++ instead. Microsoft saw Borland's success and then did their own C++.
We sold a lot of Zortech C++ compilers to Microsoft. They used it to develop COM.
I heard rumors that Microsoft was developing their own OOP C, called C*. I've never been able to confirm it, though.
Your perspective on this may be distorted due to your personal involvement. Do you believe MSVC++ or Turbo C++ would still have existed without Zortech C++ arriving first? Because if so then I don't think you can really take credit for C++ popularity on the PC.
> Do you believe MSVC++ or Turbo C++ would still have existed without Zortech C++ arriving first?
Nope. As I mentioned, Borland was working on their own OOP C language. ZTC++'s success caused them to abandon it and do Turbo C++. I know this because of my conversations with Eugene Wang. And Turbo C++'s success caused Microsoft to do MSVC++, which was quite late to the game.
Before C++, the newsgroup traffic on C++ and ObjC was about the same. The C++ traffic took off after ZTC++ was released.
You can verify some of this by:
1. looking at newsgroup programming language traffic over time
2. looking at the release dates of Zortech C++, Turbo C++, and MSVC++
3. looking at the programming magazines of the time and what language/compiler they used
4. looking at the programming magazines at the time and seeing they were all about programming on the PC, not mainframes, and not Unix.
Little known fact - when I was contemplating enhancing Zortech C into C++, I was concerned about AT&T's intellectual property. I contacted Ryan Williams (I think that was his name), AT&T's IP lawyer. I asked him:
1. do I need a license to create a C++ compiler?
2. do I need to call it something other than C++?
He laughed and said, no, I could do whatever I wanted. He also thanked me for being the only compiler guy to ask permission.
I read about his passing a few years ago. He was a solid guy.
I looked up my notes. It was William Ryan.
Something that not many people consider. It is almost certain that C++ "saved" C by existing. Without C++ there would be an enormous pressure to add more features to C itself. One reason why C committee could get away without adding much over the years was that they could nod towards C++ and say "that's their job, not ours". And if later didn't exist who knows what kind of language C would become. Classes? Templates? Lambdas? We can only speculate.
I don't know if this is true. In the 80s there were many languages that were C with additional features or C preprocessors that added and experimented with features similar to cfront. You had OOPC (object-oriented pre-compiler), Objective-C, C*, Concurrent-C. People were experimenting in all kinds of ways by taking C and trying things out with it.
I think it is absolutely true, because adding features to an experimental language that has no tools or ecosystem surrounding it does nothing and people know that.
Niche experiments having features doesn't accomplish anything, but adding just one more feature to C seems plausible.
With C++ people could point people to another production ready language compatible with C that people could use, so there was somewhere they could do and an example of the feature working instead of someone promising silver bullets in theory.
> adding just one more feature to C seems plausible
I thought it would be a couple months to add C++ to my C compiler. 10 years later...
> It is almost certain that C++ "saved" C by existing.
Perhaps. But in the 80's, C was the most practical language to use on the PC, by far. And porting C code to other platforms was easy.
Yeah, OPs claim feels disconnected from C’s identity. C stayed conservative because the areas where it excels (to this day) benefit from its “portable assembler” design history. A history with no C++ wouldn’t have changed that, instead another (either non-C extended or alternative C-adapted [Obj-C, for instance]) language would have taken the market C++ did; likely with a larger runway time due to the lack of interoperability/superset compilation.
Hilarious coming from the guy whose shitty Multics ripoff directly inspired "Worse is Better"
From the essay:
"Unix and C are the ultimate computer viruses.
A further benefit of the worse-is-better philosophy is that the programmer is conditioned to sacrifice some safety, convenience, and hassle to get good performance and modest resource use. Programs written using the New Jersey approach will work well both in small machines and large ones, and the code will be portable because it is written on top of a virus.
It is important to remember that the initial virus has to be basically good. If so, the viral spread is assured as long as it is portable. Once the virus has spread, there will be pressure to improve it, possibly by increasing its functionality closer to 90%, but users have already been conditioned to accept worse than the right thing. Therefore, the worse-is-better software first will gain acceptance, second will condition its users to expect less, and third will be improved to a point that is almost the right thing. In concrete terms, even though Lisp compilers in 1987 were about as good as C compilers, there are many more compiler experts who want to make C compilers better than want to make Lisp compilers better.
The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++."
https://dreamsongs.com/RiseOfWorseIsBetter.html
I highly respect the Ken Thompson and the rest of the old UNIX hands, but wouldn't they admit that the real world is messy and the best solutions in isolation don't always win?
Their creation C and UNIX won over the more advanced LISP and Smalltalk systems because they were simpler to implement. Even their own more advanced Plan 9 based OSs could not displace the more widespread unix-like systems.
It seems distribution and 'good enough' to rely on always wins. IMO, dynamic languages like Perl, Python, Ruby, JavaScript, PHP and the heavily marketed Java provided good enough high level facilities that have prevented people from reaching for Lisp and Smalltalk.
Looking at it through this lens, perhaps C++ was the vehicle for strapping some high level facilities on a widely adopted low level performant language that made it just good enough of a technology for wide adoption.
You think that LISP and Smalltalk aren't widely used is because they weren't easy to implement in the late 1980's? There have been many languages that have risen to prominence in the 40 years since, yet LISP and Smalltalk remain niche languages.
My opinion is that Lisp and Smalltalk are too pure and abstract. C is heavily tied to the real world of computing and can be easier to grasp for beginner. But try to explain variable bindings (instead of assignment) or message passing (instead of function calls) to a beginner in programming. It’s not that they’re hard to explain or understand, they’re just hard to be completely grasped without a foundation in computer science. They’re too alien.
Which new languages have risen to prominence outside of a niche?
Rust, Python, Java, Ruby, Scala, Swift to start with. These are languages with very wide adoption. Objective-C is very Smalltalk-like, but it is being phased out for Swift.
These became popular after Moore's law made it possible many years after C/Unix had become the standard.
And they became just good enough that more people didn't go into Lisp/Smalltalk instead.
But C++98 is so different to even C++11. Bjarne's book covering C++11 read completely differently to the 98 version, I found.
That just adds to the incoherency.
It's why I've found Rust a joy - enough had happened in programming languages, that it was able to reinvent C++ with some of the best parts of the Haskell/ML/Scala family, some of the ergonomics of Python/nodejs, and bringing the borrow checker too.
C++ is this weird amalgam of like 7 different generations of languages.
But by far the worst part is the developer hostility behind the idea of UB. "Oh, this is not an error, it will compile, we will just secretly stab you in the back."
You can get good and avoid it, and there are tools to help you, but why is that at all a reasonable stance for the definition of a language?
Saying this about Rust and C++ is like saying the kitchen you just built is cleaner than the old kitchen you used for 50 years. Get back to me in another few years.
I agree for the comparison.
Now for Rust I don’t think it is going to change a lot. Because it is based on ML, it has the best foundations and all features are known. The question is more how much Haskell vs script/imperative do you want your language to be, and what’s the purpose of the language rather than we had the wrong paradigm and found a new better one. For Rust 99% of its features are known and most are already implemented.
Maybe things around the borrow checker, and await, but beyond that nothing as much as what C++ saw in its history. Even more when for instance you see the article from the guy doing Gleam where traits (impl) are not necessary, all you need is data and function to have the same functionality. Or how ML have been the main factor to most new languages or new features to existing languages.
The future is ML, with languages dedicated to specific use cases and niches. And also ML languages easily readable by AI.
Then I will feel the same about Rust! There's nothing wrong with wanting to throw out the janky accretion every 30 years for a redesign.
After 3-4 years, sure. But eventually enough has changed it's worth redoing.
I built my career on C++ and I agree with you. Rust is just superior in almost every way. C++ is dead to me for new projects.
> IMO, if c++/cfront didn't ride on the tails of c, I'm skeptical it would've seen widespread use
Obviously. C++ was a "better C" in that you could keep a lot of your "legacy" C code while improving your codebase piecemeal with C++ features. Your management didn't even have to care, in that C/C++ was accepted as a valid descriptor even by people who should have known better. It's a wonder Java/C# and Perl/PHP never caught on.
Nowadays I got into the habit of saying C++ was C's Typescript.
> kiss goodbye to any notion of being able comprehend existing code that's not written by you (until llms arrived).
In my experience it takes a while (<=3 months) for folks to become proficient when they see an alien dialect of c++. That may sound totally unacceptable to you (fair). Cpp is also a “big tent” language in that it is genuinely multi-paradigm.
I think LLM’s might help, but sometime they hurt too (confidently/persuasively wrong analyses). The gain is large for small/trivial contributions. For changes that require genuine understanding, I’m not sure (large error bars personally as to whether the sign is even positive).
UNIX founders never liked C++ that much, note how Plan 9 and Inferno only have C as the systems language, with the Alef experiment, and later Limbo.
Followed a couple of years later contribution to Go's design, exactly to avoid C++ at Google.
The last one from Scott Meyers was the final nail in the coffin for me. The chapter about auto and template parameter deduction specifically. Since then, I've been happy with Golang and Java.
Auto is great
Since I've been working in C++ a lot recently I decided to watch the video as I waited for a build to complete. So the length is about right. And fortunately, the video is a delight!
I have read as much as I can on the history of C++ and I'm looking forward to watch this. I find the process of it's evolution deeply fascinating.
I feel drawn to watch it in the same way I was drawn to watch Breaking Bad.
> the process of it's (sic) evolution deeply fascinating.
... as it is disappointing.
Not everything that can be done should be done.
Wow is this just a shitpost (it was funny!) or do your builds actually take about an hour? That's nuts, if so.
A fresh build of a large C++ project taking 1 hour does not sound strange at all.
If that's an incremental build though (i.e. simply rebuilding after changing a few files), there's something very wrong.
FASTBuild has been a game changer for our team recently if you have extra hardware sitting around.
https://www.fastbuild.org/docs/home.html
Your org needs better distributed build caching if you can't get that number lower. All builds should be "incremental" with appropriate caching.
Not everyone in the world who compiles a C++ project is necessarily doing so for an "org"
It does if you have an even remotely reasonably specced development machine.
Yes, although in all honesty the actual compilation is somewhat small compared to the many layers of unit, simulation, integration, and regression tests. All those corner cases take a long time to explore.
Personal opinion: C++ is the most elegant language I have used (for about 15 years). If you are the 'systemizer' type and like to have an extremely precise mental model of the thing you write down to the last bit, nothing beats C++. I acknowledge the limitations and uncertainties that come from compilers etc, but still
An elegant language is one that achieves a lot with very little. Forth and Scheme are elegant languages. You're free to like working in C++, and you can sure achieve a lot with it, but I don't think it's controversial to say that it does not do so with very little.
It's easy to make a minimal language that can technically do everything via Turing completeness. That can look elegant until you start writing reptitive or hard to read code with it. Golang "if err" is a classic.
The notion of Turing completeness isn't relevant here, it encompasses almost none of the interesting distinctions between programming languages in practice. And yes, simplicity alone isn't what matters here, or else we'd all be applauding Brainfuck. What matters is strength:weight ratio, or the interesting expressiveness and abstractive power of your language weighed against its surface area.
Makes sense. This appears to be also a symptom of whatever you work on most (or start with), your brain starts to absorb that into its way of thinking.
[dead]
> If you are the 'systemizer' type and like to have an extremely precise mental model of the thing you write down to the last bit, nothing beats C++.
I would say the same thing of Rust.
I very much prefer to work in Rust but it does force you to design things in an counter-intuitive way in certain situations (linked lists for the canonical example). Specially for lower level software I find C or C++ to allow for much more flexibility and thus the most straightforward design possible.
I really don't think Rust does, but that's if you're outright refusing to use `unsafe` anywhere. Might be a little noisier if you're using things like ManuallyDropped instead of just using raw pointers, but the language doesn't stop you from doing things in ways you would with C or C++, it encourages you to encapsulate the hard parts so you can worry less about correctness of 98% of your codebase, instead of fearing incorrect behaviors can silently sneak in.
That's absolutely correct. Wild to see it downvoted without explanation, while you preemptively mentioned the tradeoff that you do need to worry about correctness in that case (just as much as in C/C++), but that only applies to a small part of your codebase, so it's still a huge benefit.
The only downside is that unsafe rust is more verbose than C/C++.
Can you please share an example of the precise mental model of something?
I would think c would?
So happy to see Andrei Alexandrescu was included in this documentary. His book on modern C++ design was a mind opener at the time I read it. Maybe still is today. Anybody else read it?
His talks are some of my favorites; he's a great speaker. Very engaging and has a great sense of humor, which he uses to great effect.
It still amuses me, but Andrei's books were the "last straw" that pushed me away from C++ for many years. Great books, truly, and they helped cement the notion that I wanted to move on to a different language. (Go, at the time.)
I seriously hated the book, too. The title should have been "Cute template tricks to make you feel smart and increase compile time, when to use: approximately never". I think about two things from the book caught on, one of them how to deal with lists of template arguments pre C++11. It's kind of horrible, but was sometimes (more or less) necessary.
Yes, I feel the same way. I met Andrei once on a Meetup in Munich, basically telling him that he taught me how to think which led to a somewhat awkward conversion. Fun times nonetheless :-)
1. Find your hero
2. Meet your hero
3. Start an awkward conversation with your hero.
It always goes like this no matter what you try.
I read it recently. I liked a few of the chapters especially how policy classes fix some issues with OO design. I do recommend asking an AI chatbot to summarize each chapter and say what the modern equivalent is since some of the idioms have improved. I think one whole section was obsoleted through the use of std::variant and std::visit.
It also caused developers to produce template-heavy code that took minutes to compile. We used to joke that these developers were "bitten by Alexandrescu".
But it was indeed a nice book that really made stataic polymorphism popular. Before that, most books focused on building object hierarchies with virtual functions, etc.
Agreed, _Modern C++ Design_ is probably the programming book I've gotten the most out of in my career.
hmm, yes it's interesting but honestly - not much of the stuff is usable IRL
the only thing i was regularly using (Loki library) for was the assoc_vector
Of course, all his books are a must read.
I always tell web developers I teach that the language of the internet isn’t JavaScript it’s C++.
Web devs are just users playing in a C++ dev’s program. ;)
I tend to think of the web and the internet as distinct things.
For the language of the web I'd probably nominate HTML.
For the language of the internet it's a lot less clear to me.
Many browser rendering engines are built in C++, so C++ is parsing the HTML. My general point is that many web/internet techs that web devs interact with have C++ one abstraction level below for actual implementation.
I agree with you, and it amuses me to no end when I (rarely) use Wt to make a simple webpage. C++ to js (very roughly) rendered by c++.
All widely used HTML engines are C++. Of the up and coming ones, Servo is Rust and Ladybird is C++ potentially moving to Rust.
In any case, Rust is basically C++ 2.0 to me because it is very much in the spirit of C++.
Rust is a tiny portion of Firefox, and sadly it is in the way of irrelevance.
It is kind of ironic that Rust will outlive Firefox as Mozzilla's legacy.
Yes I said “many” because if I didn’t qualify it someone would mention Rust.
Continuing the analogy, browser devs are just users playing in C/OS/kernel program.
That doesn't actually follow.
A C++ compiler outputs machine code that runs on a raw cpu if you want it to. The os providing a virtual cpu is just an optional extra and so irrelevant.
That is not true for someone writing php or js or anything that runs in an interpreter. C/OS/Kernel are not actually the interpreter for C++, or they are, but only in the same way that the bare hardware is. C++ is the final interpeter layer besides assembly.
Machine code is interpreted by CPU's microcode.
Playing in a sandbox no less.
An interesting opinion on this by Chandler Carruth: https://hachyderm.io/@chandlerc/116694268329657881.
He has a point. The video certainly feels more like a hagiography and I noticed the lack of critical voices. Only in the last 10 minutes they touched on some common criticisms, like the growing complexity and the memory safety issues. I still enjoyed it, though.
It's surprising that C++'s development trend continues.
When a game or program is made with C++, it's usually nice because performance is mostly guaranteed. But if someone told me to write C++ myself, I'd cry. There's too much to memorize, and the standards are too varied. When I go to a project site for maintenance and it's a C++ project, I instantly lose energy — because it's just too difficult.
I'd be happy if someone else wrote it, but it's not a language I want to write myself
Personally I don't find programming with C++ that hard. The downside is it needs a brain warm-up, and this is per project, but once that flywheel is spinning, I find it almost effortless to write code.
I have to go through the same warm-up more or less for any language I work with, so it's not that different than writing Python, Go or Java for me.
I find C++ not hard at all when working with familiar idioms, restrictions and toolings (familiar to me). But it's hard jumping into new codebases and adjusting yourself to new patterns. Recently I did a lot of programming using C++23 Modules and it was a breeze.
There's basically dozens of very nice languages inside C++. That can be a blessing or a curse.
I'm anxious for Herb Sutter's CPP2/CPPFront to become a standard.
In February this year Herb tweaked a test case. That was his last commit to his "CPP2 syntax experiment". Don't expect it to "become a standard".
https://github.com/hsutter/cppfront/commits/main/
That's a shame! It's a lovely language.
Is it really, though, or is it just in comparison to C++?
Tbh I never expected that experiment to go anywhere. I guess that leaves Carbon (and large scale efforts to rewrite C++ in Rust).
I personally really like the syntax and the defaults, and I like it more than the C++ alternatives.
What type of project actually uses C++ 23 modules in real life? What kind of toolchain enables that? When I worked on Chromium, they were indefinitely in the "maybe in 5-10 years the tooling will be ready" camp.
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
What early adopters are using them? Because my impression is the tooling still isn’t there
People using Visual C++ with MSBuild, or clang with CMake and ninja.
It’s been 6 months but last time I checked neither IntelliSense nor clangd worked with modules. The build tools have been just about functional for a while though, you’re right.
Yeah, Intelisense is a bummer, but you really need VS proper, nor VSCode, which I assume given the clangd reference.
Whereas one kind of works (VS), there is apparently no work going on VSCode Intelisense, ticket is stalled since January, and the promised announcement never came up.
CMake says they are there. Other tools mostly are not.
Nobody has said they are using them in anything important, but hopefully that is coming.
CMake has support for named modules but does not support header units or C++23 module features such as import std;
Import std has been there for a while but is experimental until gcc supports it. Gcc just for that support so it should be mainline soon.
We are now getting close to the distance between c++03 and C++11 for making basic modules work on main line toolchains and build systems. That’s absolutely wild.
Projects: https://arewemodulesyet.org/projects/
Tools: https://arewemodulesyet.org/tools/
C++20 is pretty common and gives you already a pretty nice engineering experience.
YC startup. Toolchain was Clang and sh.
Chromium is gonna be more conservative than that for sure.
Looked up what C++23 Modules were and I must say I was not let down.
>I'm anxious for Herb Sutter's CPP2/CPPFront to become a standard.
Why? It doesn't remove complexity, it (partially) hides it and makes the whole thing even more complex.
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.
I agree.
You don't learn or know C++ in the way you learn or know C.
You never have the total language spec in mind. Much of it you will never (and for some of it should never) come across.
The way I think of it
C is an abstraction of the machine, so thin it's nearly transparent.
C++ is an abstraction over programming paradigms, letting you pick how you think.
Everything else abstracts the machine away, replacing it with a VM, runtime, or model of its own.
The same way a good project has a clear model of the problem it should have a clear C++ pattern in use.
> C is an abstraction of the machine, so thin it's nearly transparent.
-Werror might help with that
> C is an abstraction of the machine, so thin it's nearly transparent.
Looks like someone fell for the C abstract machine trap yet again. No, C is isn’t an abstraction of the machine.
C Is Not a Low-level Language: Your computer is not a fast PDP-11.
https://spawn-queue.acm.org/doi/10.1145/3212477.3212479
As a corollary, all processors are C VMs, anyway.
It may not be an abstraction of a real machine. But the C abstract machine is very close to the foundational idea of how a computer work. And it’s quite easy to bootstrap.
Importantly my work involves me often being able to look at C and think about the assembly and back and I regularly work on ESP32, ch42(riscv) and atmega avr8.
I couldn't do that with mciropython on any platform.
C is a thin abstraction, python isn't.
How much of it are C extensions not covered by the language standard?
they're technically not wrong. C is literally an "abstraction" of the machine. As we know, the whole point of an abstraction is to ignore the multitude of details :-)
There are so many standards and idioms that it gets confusing. There are still legacy codebases out there — some codebase still use C++98 as their standard, others use C++11... And with Unreal Engine, the modern C++ standard is C++14, right? There are things like smart pointers, but some places don't even use them. I feel like there are just too many features. When I saw template metaprogramming — that new feature — I realized I have no talent for C++.
I have developed things with C++98, C++11 and C++14. Every of these standards are so vast, so remembering everything (even in a single standard) is not possible. Instead of knowing everything, I first fix the standard I want or need to work with.
Then I design the thing I want to build. I always design what I want to build beforehand. This takes a couple of iterations from high level to low-ish level. That last design becomes a bit language dependent. Then I select some of the core tools that I'm going to use (which kind of pointers, classes or structs, etc.)
With that design in mind, I go "library shopping" both for file formats (if any) or other stuff like vectors, etc.
Armed with the reference docs of these, I write my code with the toolbelt I have built for the project.
Some things are hard, but they are not impossible. I find thinking like compiler helps a lot.
This is true of any language. Python with flask vs django, with/without type hints. JavaScript with anhular and vue.
The varying standards are no different to major python versions or go versions - arguably there’s even less between most versions than there is in your average go release.
The differences in apps and frameworks don’t matter for day to day - std::string, Unreal’s FString and QT’s QString all are similar enough that 99.9% of the time.
Metaprogramming is one of those things; you either write it or you don’t. Knowing some basics is required but the vast majority of people use a handful of pre existing things without understanding the nuances of how it works under the hood.
> This is true of any language
Is it? Java has changed a lot, but in such a way that it's still easy to mentally map new features to the old ones, provided you have understood the core language. IDEs can even convert your code from old to new and back.
Still true for C++. Can still mentally map new features to the core language C. A modern Cfront transpiler can still be written.
Template meta-programming maps to C pre-processor macros. The sad part with both is generated code cannot be examined thus the unreadable compiler errors and slower compilation as it's regenerated every time.
Slightly off-topic: Rust can also be mentally mapped to C.
Yeah it is! Java 25 changed constructor behaviour to allow logic to run before the calls to super(). That’s an enormous change.
On the c++ side, “modern” features like span, smart pointers, range based for loops, format are all really simple to reason back to for anyone who is a programmer. Stuff like modules and concepts is a bit different, but most people aren’t in the innards of those every day, in the same way that the change in header size doesn’t affect every single Java developers code, but you should know about it.
> When I saw template metaprogramming — that new feature — I realized I have no talent for C++.
It's not a new feature. And tbh, compared to Typescript, C++ templates are tame ;)
(but yeah, deciding when to stop digging into the template metaprogramming rabbit hole requires some common sense and sanity, too much template complexity is almost never worth the hassle)
It was a new feature. Over 30 years ago now. Template metaprogramming was even featured in the ARM.
> And with Unreal Engine, the modern C++ standard is C++14, right?
Unreal Engine depends on C++20 at this point.
https://dev.epicgames.com/documentation/unreal-engine/epic-c...
When I went on a business trip for screen golf program project back then, it was UE4(CPP14), By your introduction UE5 onward, it's 20. I've updated my knowledge.
I have felt this many times. However, the effort involved in writing code does not indicate the amount of issues that code may have. This is why I prefer Rust to C++ these days - it just removes 90% of the development tail, which can be quite long in C++.
That’s true, however I tend to build my testing harnesses alongside the code I write, hence every single function and the whole flow has a testing suite ready almost immediately (via Catch2 99%of the time), and every commit is tested locally and by a couple of runners after the commit.
This coupled with generous amount of Valgrind testing allows me to catch problems early and fix them immediately. Doing this allowed me to write very performant code without any leaks or accuracy problems.
Another thing I do is making some cases mathematically impossible. If this promise is broken, code is guaranteed to crash at that point, so it’s self verifying in a sense.
Of course enforcement of this is possible due to fact that I code solo most of the time, and has the discipline to do boring things as well as the exciting and fun things.
"I don't find programming with C++ that hard."
That's the easy half.
The old joke used to be that perl is a write-only language. Hell the way I write bash is pretty write-only (basically golf). I'd say so is C++.
A lot of things are easy to write and then impossible to read or develop.
> The downside is it needs a brain warm-up, and this is per project, but once that flywheel is spinning, I find it almost effortless to write code.
How is that different from other languages, which don't need the brain warm-up?
The difference, if you split hairs, that the brain warm-up takes a bit longer. Maybe a couple of hours, or a day at most.
Otherwise it's not different for me. I don't feel different while writing with any other language. I guess the main reason is I always think like the computer first and translate that thinking to the programming language at hand.
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...
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.
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.
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.
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.
What, you rewrote std::deque? Whew!
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.
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.
Unordered map is a hash map with separate chaining.
If you don't use the STL you end up re-implementing it yourself. Usually poorly.
> 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.
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.
> 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.
That's your opinion, others won't agree and would much rather not pay the price at all.
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.
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.
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.
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.
You can prevent more than enough crashes with enough testing to make gamers happy. Even if you prove there is not out of bounds error I still want a medical device to check
Even with an extreme high level of inhouse testing (which is needed anyway) you'll never find the bugs that are discovered when a hundred-thousand gamers try to exploit every little feature of your game.
The reason to keep asserts in release mode is so that when one of those asserts is triggered "out in the wild" the bug investigation is dramatically simplified. The assert message and callstack is usually enough to figure out what went wrong. With a regular crash that happens without asserts the actual reason of the crash may already be obfuscated enough that a useful bug diagnosis is no longer possible. E.g. an assert is usually triggered very close to the bug, while crashes are usually only the end result of a whole cascade of events triggered by an initial bug.
Fair, but the counter is eventually you have enough real world testing to have confidence and so you no longer need the assert. If 1 in 10 user's have a crash that is unacceptable. However, what if it's only one in a million, or one in ten billion? At what point can you say, 'it's no longer worth worrying about that rare case.'
And this is why games are different from medical devices. In medical devices, I would worry anyway. In games, especially in a tight loop, it may be that extra CPU instruction is an important difference in performance.
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.
Sometimes there are ways of getting runtime bounds checking.
For example, both of these return the 3rd element of a std::vector:
Yes, with the trade-off of essentially requiring exceptions, which are also banned in some codebases.
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.
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.
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.
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.
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!
Which is why one of the security measures in C++26 is to make bounds checking idiomatic, finally.
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.
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.
Seconding this - boost::unordered_flat_map was only added in December 2022 and many people don't know about it yet.
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.
Which is worse? std's mess or one you control? I'd take any random game engine's STL over std any day.
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
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.
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.
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
> 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.
> 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™.
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 :-)
You can construct the vector with a given size. As long as you don’t push_back, beyond capacity, these should be o dynamic allocations.
If you want to get f cy you can also give it a custam allocator and throw an exception if you do this by mistake
> As long as you don’t push_back
But that's the point. You _can_ push_back, or resize, or reserve, etc. etc. My claim is that the more common use case is the one where this _cannot_ happen.
> If you want to get f cy you can also give it a custam allocator
And then nobody will want to use it, because that's not interchangeable with containers vector with the default allocator, and also difficult to understand. I mean, look at PMR allocators, which are not even that custom. They see very little use I'm afraid.
Well, if you want to, I can write you a forwarder-wrapper around a std::vector that would inhibit allocation-inducing operations. Now, getting it into stdlib, that's a different matter entirely...
Also, do I understand correctly that you want both the capacity and the size fixed, i.e., the container's elements have to be pre-constructed and supplied to the constructor via an initializer list?
What operations could such frozen vector offer that std::vector does not? If there are none, it doesn't need a separate data structure.
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.
How are any of these achieved by a vector-like type with capacity frozen at construction time?
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.
This is how I designed my vector in C. Note it is still not frozen as you can use realloc just fine (even with good performance) and/or external tracking of the capacity in tight loops.
https://uecker.codeberg.page/2025-07-20.html
I probably will still add a version with capacity, because people may insist on it, but personally I like the one without much more so far.
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.
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.
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.
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.
Nowadays also used by many of us (wrongly) to refer to the overall C++ standard library, instead of what was inherited from C.
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.
The article might be slop, but the problems described in it are definitely real ;)
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
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.
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.
Yet they spend a lot of time complaining about features that were deprecated or removed.
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.
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.
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.
You're right that C++ has a lot of features. But like mentioned elsewhere most projects define their own conventions and the subset of features that they use.
Also the nice thing about having a large set of features is that C,++ allows you to write very nice abstractions (or not) at both very low or at very high level. In other words you can be very low level with online ASM and bit operations and bit and direct memory manipulation or very high level almost like a script language. Whatever the problem domain needs C++ has got you covered.
You can be pretty productive even with 70% of the language :) It is a common misconception that C++ is suitable only for game engines and similar domains. It is perfectly fine for applications domain as well.
As a side note, regarding your profile info, unless you are based in North Korea, please at least add one 0 to your rate. You'll get more long-term and high-quality clientele.
> You can be pretty productive even with 70% of the language
Or even far less than that. I like to use it as C with lambdas and namespaces. Sprinkle in metaprogramming as needed. Even just not having to remember to call cleanup code thanks to dtors would alone be enough to sell me on it.
I once wrote a pure C project years back that made heavy use of complex numbers and 2D/3D vector math. At one point I got so fed up debugging my expressions under an endless parentheses-hell of `vadd(vmul(vadd(...), vadd(vmul(...))))` that I threw my hands up and changed the file extensions to .cpp just to use std::complex<T> and enough operator overloading to type vector expressions like a human being.
Only by people that started working in Web during the 2000's.
Back in the 90's, it was the main business language alongside Smalltalk, Delphi and VB.
Hence the plethora of C++ frameworks to chose from, sadly most dead since .NET and Java took over most of the use cases.
Honestly, I don't expect to find clients here. Fundamentally, you have to trust me to give me work. The amount of money doesn't really matter much to me.
I mean, the lower rates arouse suspicions. The higher you value your work, the more trustworthy you appear to clients.
Thank you for the advice. I'll think about it. Or maybe just remove the price altogether.
One of my hobbies is rummaging around thrift stores appreciating tacky things from bygone eras, sifting through ill-conceived modern junk, and delighting in simple, solid tools where I can find them.
That's what it's like to be a C++ programmer.
> There's too much to memorize, and the standards are too varied. When I go to a project site for maintenance and it's a C++ project, I instantly lose energy — because it's just too difficult.
I've been feeling this way about web dev for a while now, and sometimes look at C++ devs with jealousy, wishing that the crazy amount of memorization/varied standards/rough maintenance/high difficulty I experience were only limited to the language that I write.
I don't really understand this perspective. You don't need to memorize anything to learn a new programming language. You choose a medium-sized project you've already done in another language, start with "Hello world," and add one line of code at a time until the project is done. When there's something you need that you don't know how to do, you look it up.
You'll end up with a strong understanding of the subset of the language that's actually useful for the thing you want to build.
You get used to writing C++, just like you get used to writing any language. I've been writing C++ for quite some time already, on a daily basis, and it became second nature. Though I remember how much of a pain it was when I initially move into it
It's truly baffling. I was very frustrated with C++ (pre-LLM era) to the point I actively left a good job just so I can work on Rust.
>There's too much to memorize, and the standards are too varied. When I go to a project site for maintenance and it's a C++ project, I instantly lose energy — because it's just too difficult.
If you'd already been using it for 10+ years you wouldn't feel that way, because you'd already have memorized a lot of it.
Except the language keeps growing, with
- new features overlapping old features previous standards without replacing them or deprecating them. - new features not usable by the layman - ...
See function::copyable_function vs std::function, modules, coroutines, Reflection syntax is cryptic at best, ...
You don't have to use them. There's a handful of nice to haves in modern releases but its totally fine and sane to just ignore whatever the committee is distracted by at the moment.
Hell, if you wait long enough, they'll just deprecate it before you can care to bother.
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.
We're talking about different things.
Im talking about your own personal coding. You dont have to use the new things. You dont have to know them to decide to discard them. In fact, the criteria to discard something is to not know it. You generally shouldn't be using things you dont know anyway.
The fact that other people use things you do not know is not a reason to stress out about the dumb pace and direction c++ is moving in. It is possible to enjoy a life free from fomo about the c++ standards goalposts.
> But if someone told me to write C++ myself, I'd cry. There's too much to memorize, and the standards are too varied
If someone tells you to write a web app, do you also cry? Surely there's more JavaScript frameworks than subsets of C++ at this point, no? Do you also go memorize all of them? Or do you just quickly pick one, and then only learn that one, and forget the rest exist? Because that's kinda how you approach C++. You pick a subset (like, say, just modern C++, only caring about C++17 & later or whatever), and just use that. And move on with your life. There's absolutely no reason to learn how std::auto_ptr works because it's dead in the same way you aren't learning how PHP & CGI works if you're making a modern web app. They're dead relics of the past that you can just pretend don't exist.
Not really, despite all its warts, it is exactly because of them that many reach out to C++.
Many of us don't like C, it was already too little and too unsafe, when the first C++ compilers started to hit the market in early 1990's, hence why all desktop OSes moved into C++ for their frameworks.
The return to C has caused by the rise of FOSS, UNIX winning the server room, and early GNU coding standards to use only C as main compiled language.
Additionally as many other programming language ecosystems have discovered, it is easy to beat C++ in version 1.0, and eventually all of them grow to get the complexity of their own.
I reach for C++, because the language runtimes, compiler tooling, and GPGPU frameworks I care about are partially written in C++, and I am not in the place to be writing new ecosystems myself.
I work maintaining the toolchain and language runtimes for a commercial safety-certified embedded operating system. I am deeply familiar with C and C++ because I live it and breathe it every day and have done so for over 40 years.
Most of our customers use C, probably for historic reasons but also because it is much much easier to reason about and that becomes very important when auditing for functional safety certification. If someone's life depends on your software, you really want to be able to reason about its correctness because orange jumpsuits enhance no one's complexion.
Many of customers are now using C++. From the problems they have reported, well, they just shouldn't. It's not that it is a bad language (it isn't) or that it is inherently unsafe (it really isn't: exceptions are safer than propagating return values as long as you use them in exception conditions, because not catching one will return you to a designed safe state very quickly, and RAII is the best thing since sliced cheese). It's that cutting and pasting from Stack Overflow, and now vibe coding, makes for massive codebases that are next to impossible to reason about. I now see a lot of problems from customers where my first reaction is "don't write code like that" and "you can write bad JavaScript code in any language, can't you?". While it butters my bread and I enjoy the language, I really recommend against using C++ for safety-certified embedded software. Stick to C.
If only C actually had fat pointers as Dennis Ritchie, one of the authors, proposed to WG14.
It is quite relevant to note that the C authors, were keen to explore Alef as alternative on Plan 9, and based on the learnings reduced C's role on Inferno, and eventually took part in Go's design.
Even though they were not keen into using C++ (Plan 9 doesn't even support it), they were also aware C wasn't to be used for everything.
> I really recommend against using C++ for safety-certified embedded software. Stick to C.
You're almost certainly better off with Rust at this point or, if you must have C-like development, Zig.
Neither Rust nor Zig are appropriate at this time for certified functional safety. Given the definition of the languages is "it does what one particular implementation of its compiler, runtime, and standard library does at this time" it's not possible to construct a workable safety case for their use.
Enthusiam and neat ideas are not sufficient to certify a development tool for functional safety.
Rust has multiple qualified compilers for several safety standards, with more in progress.
I think this hits the nail on the head. All the features of C++ help you write a code which you should have written in a much simpler way in the first place.
The return to C was caused by other languages taking over every niche where C++ is better suited than C.
There isn't even much of a "return" there. In fact, AFAIK, C++ expanded over C the entire time.
funny, I think the same about rust.
(Safe) Rust is a lot better about the "Pit of Success" design than C++
There are fundamental technical choices to deliver that, but also ergonomic things like notice Rust's []::sort is a stable sort, whereas C++ std::sort is an unstable sort. If you don't know about sort stability in Rust what you wrote works and in C++ you get a nasty surprise.
C++ has std::sort() and std::stable_sort(). You should write what you mean, and you should know and understand your tools. Blaming the tool for your ignorance marks you as significantly less than an artisan.
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
> 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.
Why, exactly, is the c++ std::sort "wrong"? There are tradeoffs both ways. You happen to prefer stable sorting to speed, but that is a preference not an objective fact.
> Why, exactly, is the c++ std::sort "wrong"?
It's silently an unstable sort, which is surprising, and then to add insult to injury it's also slower. Yeah, I know, the C++ unstable sort is so slow it's slower than Rust's stable sort.
YMMV for input types, sizes etc but generally that's what the numbers look like and though it's not universal it's actually quite common. "I bet the C++ is faster" is the wrong instinct, sometimes by a large margin.
And stable sorting typically allocates large amounts of memory, which is also an unpleasant surprise.
I prefer the C++ naming convention, because it matches my expectations. When I studied CS, quicksort was considered the default sorting algorithm, and stable sorting was therefore a special case.
My pet peeve is that standard library sorting algorithms are still mostly single-threaded. Multicore CPUs have been the norm for ~20 years, but standard libraries still don't offer reasonable algorithms for sorting large arrays.
So C++ is "wrong" because it doesn't work like something that came along 40 years later and you used first?
The problem does not appear to be in C++.
No? One of the giveaways of how unserious such responses are is that I spent many years getting paid to write C. The home where I'm writing this was bought† with money made writing C years ago. Rust wasn't even a twinkle in Graydon's eye when I started that job, let alone when I first wrote C last century.
The choice to provide the unstable sort and then add a stable sort as an afterthought smells of the New Jersey approach to me. It was easier to do this, and too bad for the users, they weren't the priority.
It's the wrong choice because if you don't know about sort stability this outcome is surprising, so this means that although a beginner probably thinks they know what "sorting" means they actually mustn't use the sorting APIs in such a language until they've learned extra material.
† For cash, I don't like to owe people money, including having a mortgage
You are failing to make an argument for why stable sorting is objectively the correct choice. Just because something doesn't match your expectations doesn't make it wrong.
There isn't a symmetry here. If you know about sort stability then you can seek out the unstable sort if you know that works for your purpose, if you do not know about sort stability then the unstable sort's behaviour would be astonishing, so stability by default is the right choice.
It's not so simple that you can just declare what is surprising. Surprise depends on context, and not everyone will have the same context as you. You say you would expect the term 'sort' to mean a stable sort, and I would expect it to always mean in-place sorting, others may expect it to use the absolute fastest way to get something sorted... Different users will have different priorities and therefore expectations.
Sort stability does not matter when the sorting key is the only thing in your data being sorted. E.g. When I sort my M&Ms by color, I never keep them in the same order, because it doesn't matter. A red M&M is a red M&M. Nobody expects their red M&Ms to remain in the same order after sorting. I do tend to expect my M&M sorting to happen in-place. I expect to not need to provide additional candy holding bowls to later clean up that were used for temporary storage while my M&Ms were getting sorted. But I'll optionally grab additional bowls when I'm in a time crunch it if it speeds things up...
Now, if we're sorting all the cars on a parking lot by color, it may be more important to keep all the red cars in the same order where they started, for example if they were previously already sorted by brand, it /can/ be useful if that is preserved. But it's not guaranteed to be important or useful. Maybe the rich owner just want to torch all their red cars all together. I typically won't have access to additional temporary parking lots only used during sorting, or maybe the owner is coming with a flame thrower at 1PM and it has to be done as fast as possible whatever the cost. There is a tradeoff, rent additional parking lots during sorting, or take more time and do in-place stable sorting, or jumble up the car brands.
So what I want is control. That's all. Whether or not the ambiguous term 'sort' is stable or unstable, or in-place or not is just semantics. The only way to get clarity is to either use prior agreement, or to not use ambiguous names. Maybe a language should ban 'sort', and only allow 'foo_sort_bar' names with stability of memory usage postfixes or prefixes to 'inform' the developer. Neither choice is ideal and will satisfy everyone. It's like being a DJ at a high school party.
I'm not saying that the STL is great in practice, since it appears to optimize for usage flexibility with defined algorithmic and memory complexity at the big-O level, and mostly disregards actual real-life metrics. Arguing, however, that a language or library is better because an objectively ambiguous choice was made differently than your expectations is like arguing for fundamental superiority of either endianness over the other.
> It's not so simple that you can just declare what is surprising.
On the contrary, of course I can tell you that I was surprised and I'm far from alone. The fact you immediately grasped for "real world" comparisons ought to tell you that you're not thinking about this correctly because these are software sorts and so have very different affordances than the real world.
The claim that you wanted control doesn't make sense in the context of C++. There are in place stable sorts - the bubble sort you may have seen in class years ago is one, but C++ doesn't promise one in its standard library. However it does provide an unstable sort, which it just names "sort" and that's what I'm pointing at as a problem.
As to the "absolute fastest" you're in the wrong place if you've used a generic comparison sort expecting the "absolute fastest". For the machine integers it's usually not even the correct category of sort for "absolute fastest". But the C++ standard library is the wrong place to look even if you did need a generic comparison sort, because so much crap C++ exists and maintainers are scared to change anything for fear of what may happen.
Did you know libc++ didn't even have a guaranteed O(N log N) sort until the Joe Biden presidency? The introsort paper was written last century and the C++ standard itself did finally incorporate this basic requirement in 2011, but it took another decade for the Clang team to fix this.
Ok, I'll keep it short: I'm far from alone being surprised that a sort allocates temporary memory...
C++ is used by a lot of different people with a lot of different background, and... expectations...
My point is that "sort" is ambiguous and having expectations on ambiguity and arguing that a certain one is better is like arguing little endian being better or worse than bit endian.
> Ok, I'll keep it short: I'm far from alone being surprised that a sort allocates temporary memory...
In a sense I'm sure this is true. C++ programmers routinely report being astonished about all sorts of properties of the language they have previously insisted they know well and who could blame them (for the former, at least).
Again, this is not symmetrical. LE and BE are symmetrical, if you have to pick one there isn't a "safe default" that isn't surprising to people who expected the other one†. In contrast sort stability isn't like that, all stable sorts also meet the criteria for an unstable sort. Likewise all the in-place sorts meet the criteria for an allocating sort.
C++ chooses to offer an unstable sort just named "sort". It doesn't offer a stable in place sort at all, but it does offer a stable allocating sort and names that stable_sort
† But what you can do is where it matters you explicitly offer the LE and BE options and silently whichever is native on your target is fast. Users can write whichever they meant and their program works rather than "Oops, by default on this platform it's the opposite byte order, there's a special conversion function to run". Needless to say C++ doesn't do this either.
The language is fine, mostly, nowadays.
The ecosystem isn't fine - just to get a project going requires picking a non-trivial set of tools and approaches, none of which the C++ standard enforces or guides to.
For example, will you manage dependencies via packages? If so, with what? What will you use for building your project? The list goes on and on.
No it's not.
The language keeps growing, with
- new features overlapping old features from previous standards without replacing them or deprecating them (function::copyable_function vs std::function, std::less<> key for transparent lookup in maps)
- new features not usable by the layman (coroutines ...)
- Cryptic syntax (reflection...)
- Stuff you are told not to use because of performance reason and that cant be fixed because of ABI (regex)
- Compile errors that are 1km long (no, concepts are not helping here, the 'nicer' message is still buried into a hot pile of template instantiation callstack).
I wonder how many programming languages would be able to devoid of all or some of these problems when they are 40 years old.
It's easy to compare new and old languages, and saying older languages are wrinkly. Let's see how other shiny programming languages look like when they are 40 years old.
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.
There are two kinds of programming languages: the kind everyone complains about and the kind nobody uses.
So a bit like Python or any other language of similar age.
Working occasionally with modern Python helped me love and respect C++ even more.
Python3 is what, 15 years old?
I start counting from Python 1.
Well if c++ had the liberty of scrapping the language twice in the last 30 years I'm sure it would look better too.
Python 2 to 3 mess is exactly why all languages think twice about breaking backwards compatibility.
That is probably what they should have done ..l
I personally find the lack of native package management in C++ as a blessing. Go, Python, Rust has it, and this always causes pulling in infinite number of packages for any trivial operation.
sudo-rs was pulling in 1M+ LOC as its dependency chain at one point. I believe they removed the biggest offenders, but I didn't check it recently.
That's one way to look at it, certainly. There are several OK options in that space, e.g. Conan (2) and vcpkg.
C++ needs to die. I get so many people are invested in it and so much code is written in it. I used to be a fan and it's still my main job. But, in 2026 with LLMs able to find all the exploits, and with more and more adversarials, we need a language that is opt-out of safety, not C++ which is opt-in + super vigilance to get safety. It doesn't work and decades of experience proves it.
When LLMs find all the exploits without the source code, they should find them even easier worth the code, no?
And replace it with what?
https://www.memorysafety.org/docs/memory-safety/
C++ was a superb language for its time. There was nothing faster with as-powerful abstractions. It showed how far you can change a language too, with C++11 being a massively better language with shared_ptr and company.
It took in almost every idea, and the battlefield showed us which do work and which don't. We get to keep RAII, move vs copy, smart pointers, placement-new, and generics. We get to drop auto_ptr, copy-by-default, its specific exceptions implementation (fight me), multiple virtual inheritance, and templates as full code substitution.
In my opinion the battles have played out, and Rust is the best sum-up of what worked (it even inherited the compile times! Lucky us!)
I love a free documentary about something that I'm passionate about. So many thanks.
However, I'm a my own kind of weird. I cannot watch a documentary that's made out of people saying short sentences. I get that it's made to 'have them tell the story', but I need a narrator to tell me what to think because I get distracted.
Still lots of love to the creators, of course.
I‘m out of the loop: we‘ve had Python, Clojure and possibly something else recently. Is that a series by the same people working through several languages? Is it happenstance? Is it a trend, and every programming language is now scrambling to get their own video documentary?
Yes, these are the same people: https://www.cultrepo.com/
Apparently, they are making documentaries about open source software.
That‘s cool, since it establishes a brand. If one was done well, the others probably are, too, so even if it‘s not your language of choice, it will be interesting.
For what it's worth:
I had an idea for a special reminder app I wanted for myself. It's complicated enough that it comes to 9,000+ lines of code. I wanted to write it using the C++ UI library wxWidgets, because I like that wxWidgets uses native widgets, and is cross-platform, and that it's easy to make an app look nice. And that it doesn't use tons of memory.
There's a wxPython library, but I didn't want my UI to be limited due to whatever gaps may exist in that wrapper.
So I had AI write it in C++. Took about a day for me to get it done. It's perfectly solid. It did hit a couple of memory errors when I first used it, but I could give the AI MacOS crash report and the AI fixed the bugs easily, with no other involvement from me. (I compiled in a debug-friendly mode; no downside to that because it was just for me and was plenty fast enough.)
25 years or so ago, I was a fairly good C++ programmer. Haven't touched it since. And that includes this application, which was completely AI-written.
Do we really have to shoehorn AI into every single thread? It's really getting tiring.
Hey I'm curious on how your reminder app works and to what effects, if you're willing to share. I'm on iteration 3 already of my reminder app, also vibe coded, and it helps me a lot. My first one was inspired on Remind [0].
0: https://dianne.skoll.ca/projects/remind/
My only problem with C++ is that it’s too verbose. my eyes need to parse huuge chunks of things when I just want some convenient syntax for it. otherwise the idioms are pretty universal for most programming languages nowadays.
Interesting, I don't find modern C++ verbose at all. 'auto', range-based for-loops and structured bindings did a great job at reducing the verbosity of C++98.
On top of that, C++ allows to design very concise APIs. (One of my favorite examples is sol2: https://github.com/ThePhd/sol2).
Library code involving templates, on the other hand, can be pretty complex and hard to read. Concepts and other C++20 features (like [[no_unique_address]]) are certainly an improvement, but only new projects with no backwards compatibility requirements can actually use them (unconditionally).
C++ is quite amenable to making things less verbose. For example: Instead of a standard library algorithm taking a pair of iterators, you could have a function taking a container and calling the other function with its start() and end(). And then, with newer versions of the language, you can use a ranges-based function. There are lots of such syntactic hacks, from `using` through typed literals all the way to preprocessor macros (which we want to avoid, but are still there).
That's how you emulate language features that aren't there originally. I've "impelemented" a static code block, like in Java:
https://stackoverflow.com/a/34321324/1593077
and that's all in C++98. The implementation is a bit ugly but the use is terse and self-expalantory.
That's just terrible, I love it.
The trouble with that is the more mental capacity you exert on the language the less you have available for the task at hand.
Try Java
hard pass :D
isn't kotlin supposed to be the future for JVM?
Kotlin is the future of maintenance nightmare and Jetbrains lock-in.
seems to work for android though
wild that c++ is apparently the fastest growing top 4 language right now
I'm going to rent the local cinema and invite all my normal friends and family for this. About time they watch something decent.
What a lineup of contributors—Stroustrup, Stepanov, Kernighan, Lattner, and more in one film. Forty years from 'C with Classes' to the fastest-growing of the top four languages is a remarkable arc, and it's nice to see the people behind it get their due. Adding this to the weekend watchlist. Thanks for sharing, Herb!
I haven't watched this yet. With all due respect, why John Romero instead of John Carmack for a C++ documentary ?
Romero was a prolific programmer himself back in the day. He's become more known as a designer because Carmack took over as the main engine programmer at id, but Romero was still writing tooling and editors, in addition to doing the level design.
Wow! This is an excellent info.
A documentary can't always get who they want to get.
I'm pretty sure they first asked the other John and got a rejection :)
Thank you for releasing this for free! :)
I obviously don’t know them personally, but what I get from this old school generation that have been a pillar of computer science and, why not, modern human history, is just a tiny little bit more humbleness than “influential” people nowadays.
They may be humble in their older age but the good majority of people on the list were known for anything but their humbleness back when C++ was a much more dominant language.
Using "humble" to describe a list of folks that include John Romero is certainly an interesting choice of adjective.
Time to stop hacking on my C++ codebase (https://github.com/sourcemeta) to watch this over dinner!
With great power comes great responsibility and blown off legs.
> currently (as of Q3 2025) the fastest-growing of the top four languages in the world… +90% users in the past 3.5 years.
Because of AI, right?
C++ is one of the languages less suited to the strengths of coding agents.
The language which still supports C-style pointers, arbitrary datatype conversions, and inherits architecture-specific undefined behavior gives you too many ways to fail at solving a problem.
As a programmer, I love coding in C++ because I know what I'm doing. I'd hate reviewing C++ code though.
Those Python AI libraries....
If this is a rhetorical question I genuinely don't know what's the implied answer. Why would AI specifically make C++ grow?
A few reasons: 1. Header files make C++ verbose. Header files are well within LLM's ability 2. LLMs can handle setting up cmake for you 3. C++ is very well documented relative to (most) newer languages 4. LLMs can port modern features like websockets and build API wrappers easily, reducing the disadvantage against web (since most documentation is for JS/python/go)
Coding languages have been developing for speed of (manual) writing - akin to how human languages did with modern alphabets. Now that writing is a lot easier, languages will likely evolve towards a focus on execution (or in the case of human languages, speed of reading and precision of understanding)
All of those seem like barriers that make C++ unappealing in general, but you're deciding to overcome the barriers using an LLM and seeing that as a strength somehow?
That's like every application of LLM-coding I have ever seen people talking about.
Yeah, C++, the language known for its speed of reading...
Just speculation, but I think we would expect a language to grow if AI is effective with it. C++ has a lot of training data. Most large software projects are written in C++: web browsers, compilers, 3D renderers, game engines, UI toolkits, etc.
AI is also probably more effective with statically typed languages since the compiler catches a wider range of errors.
Ideas:
- more accessible now that AI handles the high tooling activation energy
- more history and pre-AI internet content
- pybind11 is pretty popular to pair Python logic with C++ performance
- cpp committe is pretty bullish on new contracts and reflection features making C++ a glue language that AI can write well
The GPGPU frameworks and JIT compilers that actually make those Python libraries usable.
Partly - the documentary gives that a mention https://youtu.be/lI7tMxzSJ7w?t=3862
Also
>It is because we have enduring demand for languages that are good at performance per watt.
(1 min in from above link)
Let's assume that it's because of AI for this case.
Is this good or bad?
but do vibe coders even use c++? won't they use js or python?
Yes, they need it for the AI libraries they call from Python.
Reddit's r/cpp has always had some level of "My First X" posts where somebody goes from their first C++ lesson to being confident they've written the "World's Best X" in about a week. The AI slop made this much worse because now the author has been told by ChatGPT or whatever that they're a genius.
All the popular PLs have this problem to some extent.
C++ this remind me of my university days nowadays only doing python, nodejs and ansible
We need more of these documentaries,
Pascal, D, /Common Lisp, Fortran
Did it crash midway?
Herb's blog post links to the SlashData Developer Nation Survey, so presumably that's what the claim is based on. The company has a methodology page here [1], and it looks like the Developer Nation panel [2] is one of the sources used by that company.
[0]: https://www.slashdata.co/research/developer-population
[1]: https://www.slashdata.co/company/methodology
[2]: https://developernation.net/
Has anyone heard of any of these companies before?
And I wonder what the number is for other languages.
They want my email just to look at their "free report". Sorry that's not good to happen.
Hi, I'm a Principal Market Research Consultant with SlashData. We've been around for more than 15 years, and we work with the largest organisations in tech when it comes our market research on developers (our client page include AWS, Google, Microsoft, LF, Cisco, and so on and so on). Not bragging, but trying to assuage concerns that we are some fly-by-night org that popped up out of nowhere.
The makers of the documentary reached out to us to use our footage in the report and Bjarne has also used our report/blog when talking about the future of C++. In general, our hypothesis about its continued relevance is in line with what the documentary itself reports: developer numbers have grown massively and C++ has a very specific series of use cases that maintain its relevance.
Our methodology page is lengthy, but it can be summarised by the combination of several pieces of distinct information. We have labour statistics from various national governments to provide reference points, we use statistics from areas developers associate with (e.g. StackOverflow or GitHub) and compare against responses from inside the survey, and our own build-up of numbers based on the proportional data from within the survey (region, age, area, development, etc.). We have been doing this for many years. We also acknowledge in our reports that we are confident in all regions, but with greater uncertainty in the Greater China region, as we are a non-Chinese firm, so we have to work with partners in the region which minimises our confidence in the region.
The report lists the numbers for the major leading languages, basically any language that is used in multiple areas of development and has more than 500k users, give or take. It is not a perfect measure approach but it is about giving the most useful information at the highest level. We also exclude things like SQL because they are nor programming languages, unlike most of the other measures.
For the report, we typically have blogs available with similar information, but our free reports are designed for lead generation, which is why emails are asked for.
You can hear the engineer in that second question. They hear a wild statistic pulled out of someone's ass and ask what is that sticking to the side?
Is it better than the Erlang documentary?
Hello Mike.
(if you mean that film, most likely no.)
Hello Joe. Is the system working?
Good, thank you!
Pretty good.
[flagged]
[dead]
[dead]
[dead]
[dead]
[flagged]
I have the utmost respect for Casey, but his disdain for Stroustrup is unfounded. The fact of the matter is C++ occupied a niche in the right place and at the right time, and it grew from there. Many mistakes have been made, but Stroustrup is in no way personally responsible for all of them and I don't think Stroustrup is a bad programmer (something I've heard Casey say in some of his videos). You can argue that the committee route is not the best, but C++ is here to stay and by some metrics adoption is actually growing.
I agree. His negativity has probably detracted quite a few people from him that otherwise are quite aligned. Still, his historical remark is rather peculiar.
As for the language, yes, sadly, it’s with us seemingly to stay. I code it professionally and I can’t find a single interesting, or even good, thing about it. Apart from wide adoption of course. Everything about it feels extremely badly designed from the user perspective (though it’s probably technically very impressive) with many details, that probably the sanest strategy is to use a small subset of the language. At least I don’t have to use STL at work, that’s something positive, I guess :)
Strangely, I've never seen any nice code from Casey despite all of the mud slinging he's done over the years. Maybe it exists somewhere but I watched a lot of Handmade Hero when it was starting off and the code was a mess.
It feels as though he just attracted an audience of junior developers who take everything he says as gospel, as is often the case with social media programmers. Lord knows I've argued with some of them and they usually crumble as soon as they don't have one of his opinions to throw back at you.
I'm confused. I looked at the Handmade Hero videos and I had no trouble following - it was simple straightforward procedural code. As I understand it, his code does "exist somewhere". Bink 2 from RAD Game Tools, which seems to ship with practically all games. He also developed the Walk System that shipped in "The Witness" (2016). You can see his blog posts and video lecture about that. I see that he and a Jay Stelly from Valve simplified the GJK algorithm, and he talks about how to implement it. I know he has his Performance-Aware Programming series, where he talks about the technical details of hardware and how they relate to code performance. Here, I even found a tweet listing all the things he'd written till that point: <https://xcancel.com/cmuratori/status/1412839131063873536>. Perhaps you didn't look hard enough?
Can someone give me links to Bjarne Stroustrup's code? I tried searching but I'm having a hard time finding anything. I would like to verify some of the claims being made in the other comments (it's hard to tell if someone's code is better or worse relative to another person's without having access to the code and comparing important metrics and all that.)
You've attacked a strawman.
> You can argue that the committee route is not the best, but C++ is here to stay and by some metrics adoption is actually growing.
You can argue that chemical companies route is not the best, but cancer is here to stay and by some metrics adoption is actually growing.
Casey also got less aggressive when talking about Stroupstrup lately, especially after his last talk at Better software conference, where he mentioned him multiple times with a lot more historical context.