21st Century C++ (Feb. 2025) by Bjarne Stroustrup

The C++ Core Guidelines have existed for nearly 10 years now. Despite this, not a single implementation in any of the three major compilers exists that can enforce them. Profiles, which Bjarne et al have had years to work on, will not provide memory safety[0]. The C++ committee, including Bjarne Stroustrup, needs to accept that the language cannot be improved without breaking changes. However, it's already too late. Even if somehow they manage to make changes to the language that enforce memory safety, it will take a decade before the efforts propagate at the compiler level (a case in point is modules being standardised in 2020 but still not ready for use in production in any of the three major compilers).

[0] https://www.circle-lang.org/draft-profiles.html

Last weekend, I took an old cross-platform app written by somebody else between 1994-2006 in C++ and faffed around with it until it compiled and ran on my modern Mac running 14.x. I upped the CMAKE_CXX_STANDARD to 20, used Clang, and all was good. Actually, the biggest challenge was the shoddy code in the first place, which had nothing to do with its age. After I had it running, Sonar gave me 7,763 issues to fix.

The moral of the story? Backwards compatibility means never leaving your baggage behind.

> [M]any developers use C++ as if it was still the previous millennium. [...] C++ now offers modules that deliver proper modularity.

C++ may offer modules (in fact, it's been offering them since 2020), however, when it comes to their implementation in mainstream C++ compilers, only now things are becoming sort of usable with modules still being a challenge in more complex projects due to compiler bugs in the corner cases.

I think we need to be honest and upfront about this. I've talked to quite a few people who have tried to use modules but were unpleasantly surprised by how rough the experience was.

I was an extreme C++ bigot back in the late 90's, early 2000's. My license plate back then was CPPHACKR[1]. But industry trends and other things took my career in the direction of favoring Java, and I've spent most of the last 20+ years thinking of myself as mainly a "Java guy". But I keep buying new C++ books and I always install the C++ tooling on any new box I build. I tell myself that "one day" I'm going to invest the time to bone up on all the new goodies in C++ since I last touched it, and have another go.

When the heck that day will actually arrive, FSM only knows. The will is sort-of there, but there are just SO many other things competing for my time and attention. :-(

[1]: funny side story about that. For anybody too young to remember just how hot the job market was back then... one day I was sitting stopped at a traffic light in Durham (NC). I'm just minding my own business, waiting for the light to change, when I catch a glimpse out of my side mirror, of somebody on foot, running towards my car. The guy gets right up to my car, and I think I had my window down already anyway. Anyway, the guy gets up to me, panting and out of breath from the run and he's like "Hey, I noticed your license plate and was wondering if you were looking for a new job." About then the light turned green in my direction, and I'm sitting there for a second in just stunned disbelief. This guy got out of his car, ran a few car lengths, to approach a stranger in traffic, to try to recruit him. I wasn't going to sit there and have a conversation with horns honking all around me, so I just yelled "sorry man" and drove off. One of the weirder experiences of my life.

Here's how Bjarne describes that first C++ program:

"a simple program that writes every unique line from input to output"

Bjarne does thank more than half a dozen people, including other WG21 members, for reviewing this paper, maybe none of them read this program?

More likely, like Bjarne they didn't notice that this program has Undefined Behaviour for some inputs and that in the real world it doesn't quite do what's advertised.

I haven't read much from Bjarne but this is refreshingly self-aware and paints a hopeful path to standardize around "the good parts" of C++.

As a C++ newbie I just don't understand the recommended path I'm supposed to follow, though. It seems to be a mix of "a book of guidelines" and "a package that shows you how you should be using those guidelines via implementation of their principles".

After some digging it looks like the guidebook is the "C++ Core Guidelines":

https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

And I'm supposed to read that and then:

> use parts of the standard library and add a tiny library to make use of the guidelines convenient and efficient (the Guidelines Support Library, GSL).

Which seems to be this (at least Microsoft's implementation):

https://github.com/microsoft/GSL

And I'm left wondering, is this just how C++ is? Can't the language provide tooling for me to better adhere to its guidelines, bake in "blessed" features and deprecate what Bjarne calls, "the use of low-level, inefficient, and error-prone features"? I feel like these are tooling-level issues that compilers and linters and updated language versions could do more to solve.

How does enforcing profiles per-translation unit make any sense? Some of these guarantees can only be enforced if assumptions are made about data/references coming from other translation units.

I definitely wouldn't have used "<<" in an "ad" for C++ :)

(I must say that I was happy to see/read that article, though)

Generalizing Overloading for C++2000

Bjarne Stroustrup, AT&T Labs, Florham Park, NJ, USA

Abstract

This paper outlines the proposal for generalizing the overloading rules for Standard C++ that is expected to become part of the next revision of the standard. The focus is on general ideas rather than technical details (which can be found in AT&T Labs Technical Report no. 42, April 1, 1998).

https://www.stroustrup.com/whitespace98.pdf

Modules sound cool for compile time, but do they prevent duplicative template instantiations? Because that's the real performance killer in my experience.

Bjarne Stroustrup (the creator of C++) is the best language designer. Many language designers will create a language, work on it for a couple years, and then go and make another language. Stroustrup on the other hand has been methodically working on C++ and each year the language becomes better.

Seeing badly formatted code snippets without color highlighting in article called "21st Century C++" somehow resonates with my opinion on how hard to write and to ready C++ still is after working with other laguages.

I want to love C++.

Over my career I’ve written hundreds of thousands of lines of it.

But keeping up with it is time consuming and more and more I find myself reaching for other languages.

For someone who wants to get into systems programming professionally, is C++ going to be a hard requirement or can one mostly get away with C/Rust?

That's why C++ is still around today, it was built on some solid principles. Bjarne is such a good language designer because he never abandoned it. Lesser designers make a language and start another in 5 or 10 years. Bjarne saw the value in what he created and had a sense of responsibility to those using it to keep making it better and take their projects seriously.

Whenever I have an idea and I start a project, I start with C++ because I know if the idea works out, the project can grow and work 10 years later.

I always hear about “import std” but still don’t see out of the support for it. Is it still experimental?

Let us know when C++ gets rid of the mess that is header files.

Until then... YAWN.

loving he goes 'int main() { ... }' and never returns an int from it. Even better: without extra error / warning flags the compiler will just eat this and generate some code from it, returning ... yeah. Your guess is probably better than mine.

If the uber-bean counter, herald of the language of bean counters demonstrate unwillingness to count beans, maybe the beans are better counted in another way.

C++ should be known for the amount of collective brain cycles wasted on arguing what subset of C++ is the right one to use.

is the job market for C++ developers still good?

Tangential question: is there a Rust equivalent for the book “The Design and Evolution of C++”?

21st century C++? AKA Rust?

After decades of C++ development, I prefer C, modern Fortran and Rust.

Just reading the first 1/5 of this made me bored. I started my career with C++, being heavy into it for 10 years. But I've been doing Swift for the last 10 at least. I had a job interview last week for a job that was heavy C++, with major reliance on templates and post-C++ 11... and it didn't go well. You know what? I don't give a shit.

C++ and C still force a usage of header files.

For whatever reason this is probably the biggest reason I've struggled with it( aside from tooling... Makes me miss npm).

Excellent article. Thanks for sharing.

Previous from 3 days ago: https://news.ycombinator.com/item?id=42952720 (103 points, 85 comments)

Something about the formatting of the code blocks used is all messed up for me. Seems to be independent on browser, happens in both Firefox and Chrome.

Who the hell typeset this?

I dislike the style of Code used to write this. I understand that, given who wrote the article, this is blasphemy.

Opening braces should be inline with the expression or definition.

Comments can be above what they're referred to.

Combined, this makes any code snippet look like crap on mobile and almost impossible to follow as a result.