C++: The Documentary(herbsutter.com) |
C++: The Documentary(herbsutter.com) |
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.
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).
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++."
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?
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).
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.
Followed a couple of years later contribution to Go's design, exactly to avoid C++ at Google.
... as it is disappointing.
Not everything that can be done should be done.
If that's an incremental build though (i.e. simply rebuilding after changing a few files), there's something very wrong.
2. Meet your hero
3. Start an awkward conversation with your hero.
It always goes like this no matter what you try.
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
I would say the same thing of Rust.
Web devs are just users playing in a C++ dev’s program. ;)
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.
Apparently, they are making documentaries about open source software.
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.
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).
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.
isn't kotlin supposed to be the future for JVM?
Because of AI, right?
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.
- 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
+90% users in the past 3.5 years
[0]: https://www.slashdata.co/research/developer-population
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.
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.
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.
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.
How is that different from other languages, which don't need the brain warm-up?
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...
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.
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 standard library is mostly fine to use unless you have specific needs.
The bit about libraries is nonsense, sorry.
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.
That's what it's like to be a C++ programmer.
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.
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.
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.
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.
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.
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.
There isn't even much of a "return" there. In fact, AFAIK, C++ expanded over C the entire time.
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.
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.
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).
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.
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.
- 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, ...
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)
Is this good or bad?
All the popular PLs have this problem to some extent.
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.
Chromium is gonna be more conservative than that for sure.
Why? It doesn't remove complexity, it (partially) hides it and makes the whole thing even more complex.
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).
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
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.
Looks like someone fell for the C abstract machine trap yet again. No, C is isn’t an abstraction of the machine.
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.
Nobody has said they are using them in anything important, but hopefully that is coming.
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.
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.
You're almost certainly better off with Rust at this point or, if you must have C-like development, Zig.
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.
Sure, none is perfect and they have cruft and warts, but they are not such a mess as C++ is.
Hell, if you wait long enough, they'll just deprecate it before you can care to bother.
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.
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.
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.
Unreal Engine depends on C++20 at this point.
https://dev.epicgames.com/documentation/unreal-engine/epic-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)
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
- 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.
Edit: Also not sure what can possibly be downvoted here.
Regular expressions in C++ are an example "everybody" advises against using, but it's still there. vector<bool> will stay forever and so on.
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.
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.
For example, both of these return the 3rd element of a std::vector:
auto val1 = vec[3]; // no bounds checking
auto val2 = vec.at(3); // bounds checkingMost of the rest of us STL is good enough.
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.
I personally am more conservative on those things. I'll pick the fastest thing that is reliable.
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.
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.
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.
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.
STD::sort only works on a random access iterator, it won’t even compile if you try it on a list
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™.
* 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.