Live data from Hacker News

C++: The Documentary

herbsutter.com

101–110 of 334 posts

Re: C++: The Documentary

#101
post #5

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

Re: C++: The Documentary

#102
post #12

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.

Re: C++: The Documentary

#103

Earlier quoted context omitted.

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.

Re: C++: The Documentary

#104

Earlier quoted context omitted.

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

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 r…

What, you rewrote std::deque? Whew!

Re: C++: The Documentary

#105
post #71

Earlier quoted context omitted.

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 stand…

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.

Re: C++: The Documentary

#106
post #11

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 som…

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

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.

Re: C++: The Documentary

#107
post #78

Earlier quoted context omitted.

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…

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.

Re: C++: The Documentary

#108

Earlier quoted context omitted.

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

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.

Re: C++: The Documentary

#109

Earlier quoted context omitted.

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++)…

> 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 c…

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

Re: C++: The Documentary

#110
post #11

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 som…

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.

Post reply on HN