If you spend any time watching C++ conference talks, reading the standard, or skimming the Core Guidelines, you could be forgiven for thinking the industry quietly agreed to rewrite itself overnight. The code in those talks is elegant. Expressive. Composed of ranges, concepts,constexpr, value semantics, and a conspicuous absence of raw pointers.
In college, though, C++ often shows up in a different outfit: data structures, intro systems, maybe compilers or graphics if you are lucky. It is taught as “the language you use to understand memory,” not “the language you use to write elegant libraries.” Students learn pointers early. They learn manual lifetime management. They learn to fear undefined behavior.
Then you open a real codebase, written by a team that ships products for a living.
And… yeah. Something is off.
So let’s ask the uncomfortable question out loud: is anybody actually writing C++ the way C++20 suggests?
The answer is yes. But not in the way most people mean.
What “the C++20 Way” Even Is
When people say “modern C++,” they rarely mean one feature. They mean a style that has emerged over the last decade: code that leans on value semantics and RAII, prefers standard algorithms over bespoke loops, uses strong types to make illegal states harder to represent, and pushes intent into the type system instead of into comments.
In practice, “the C++20 way” usually looks like a handful of recurring moves. You see
std::optionaland
std::variantwhere older code used sentinel values. You see
enum classwhere older code used loosely-typed integers. You see concepts where older template code relied on SFINAE and error messages as a rite of passage. You see
constexprused to make compile-time decisions explicit rather than accidental.
And, maybe most importantly, you see fewer macros, fewer raw owning pointers, and fewer surprise lifetime rules.
None of this descended from on high with a standard release. It grew out of guidelines, talks, libraries, and hard-won experience. It is not “how C++ must be written.” It is how C++ can be written when everything goes right.
Who’s Actually Writing C++ This Way?
Some people really are writing the C++ from the talks. It is not imaginary. It is just concentrated in a few places.
Library authors and C++ specialists
If you work on standard library internals, Boost-like libraries, header-only abstractions, compilers, or tooling, this style is not aspirational. It is necessary.
These teams spend all day living in templates. They are the reason concepts exist. They treat
constexpras a feature, not a punishment. Their code looks like the talks because they are the ones giving the talks.
Greenfield, performance-heavy projects
New subsystems and high-end projects are the next most likely place to find “conference C++.” Think simulation, robotics, finance, and HPC, where performance and correctness are non-negotiable and the codebase is not dragging decades of baggage.
Even here, adoption is cautious. Smart pointers become the default, but they do not replace every custom allocator. Expressive types show up, but teams still measure every abstraction. Ranges do not replace every loop. Modules exist mostly in slide decks. Compile-time complexity is treated as a real cost.
It is modern, but it is modern with a budget.
Teaching environments
Academia can produce the cleanest C++ precisely because it can ignore so many constraints. When you are not supporting four platforms, three compilers, and one vendor-patched standard library, you can teach the simpler story: avoid raw owning pointers, express intent in types, and let the compiler enforce invariants.
Students often learn a cleaner C++ than they will see in their first job.
That is not a bug. That is a north star.
Who Mostly Isn’t Writing C++ This Way?
If “conference C++” were the median, this essay would not exist. Most production C++ lives under constraints that talks rarely linger on.
Legacy codebases
Millions of lines of pre-C++11 code do not get magically modernized because a new standard dropped.
Modernization is usually incremental and local. You modernize at boundaries, where it is safe. You introduce a new type here, replace a few ownership patterns there, move a subsystem toward a newer dialect when you can, and leave the rest alone unless you enjoy production outages.
These teams live in a hybrid world: “modern where possible, old where required.” And that is often the correct choice.
Cross-platform product teams
If you support old compilers, niche platforms, embedded targets, or vendor-patched libraries, you cannot assume full C++20 support.
So you end up writing C++17-ish core logic, adopting a few C++20 features where they help, and building careful fallbacks. This is not conservatism. It is survival.
Game studios
Games deserve special mention because they are often very modern, but almost never ideological.
Game teams care about debuggability, build times, and predictable performance. They use RAII everywhere. They use smart pointers where they fit the engine’s ownership model. Exceptions are often banned. Heavy abstractions and ranges show up selectively, because the cost is paid by every developer who has to build, debug, and profile the game.
Game C++ looks modern, but it does not look like a conference slide.
And it should not.
The Uncomfortable Truth
The C++ standard does not describe how people do write code. It describes how people could write code if starting today, with no legacy constraints, excellent toolchains, uniform compiler support, and deeply trained developers.
Real codebases are messier, older, and more political than that.
What’s Actually Happening in Practice
C++20 has not become doctrine. It has become a toolbox.
Teams adopt what pays for itself. They take the features that reduce bugs. They take the features that clarify intent. They take the features that do not explode compile times, onboarding, or debugging.
And they ignore the rest. Sometimes that is shortsighted. Often it is wise.
This is not failure. It is engineering.
A Hot Take Worth Saying Out Loud
C++20 is not a style guide. It is a pressure gradient.
New code drifts toward it. Old code resists it. Great engineers use it deliberately. Poor engineers misuse it and blame the language.
The difference is not the standard.
It is judgment.
A Note for Educators
If you teach C++ “the C++20 way,” you are doing the right thing, as long as you are honest about reality.
Teach it as the ideal we aim for, not the average codebase someone will inherit. The students who understand that distinction tend to become better engineers faster, because they learn both the direction of travel and the constraints that slow it down.
Final Thought
The right question is not “Is anyone writing C++ like the standard suggests?”
It is: “Which parts of modern C++ meaningfully improve this codebase?”
That is the question professionals actually answer every day.
And it is the real lesson C++20 teaches.
Fair warning: I have strong opinions 😄
Selah.
Leave a Reply