21st Century C++
24 comments
·February 5, 2025coffeeaddict1
zozbot234
> Profiles, which Bjarne et al have had years to work on, will not provide memory safety
While I agree with this in a general sense, I think it ought to be quite possible to come up with a "profile" spec that's simply meant to enforce the language restriction/subsetting part of Safe C++ - meaning only the essentials of the safety checking mechanism, including the use of the borrow checker. Of course, this would not be very useful on its own without the language and library extensions that the broader Safe C++ proposal is also concerned with. It's not clear as of yet if these can be listed as part of the same "profile" specifications or would require separate proposals of their own. But this may well be a viable approach.
bluGill
Profiles will not provide perfect memory safety, but they go a long way to making things better. I have 10 million lines of C++. A breaking change (doesn't matter if you call it new C++ or Rust) would cost over a billion dollars - that is not happening. Which is to say I cannot use your perfect solution, I have to deal with what I have today and if profiles can make my code better without costing a full rewrite then I want them.
Night_Thastus
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.
npalli
This is a Bjarne issue. For personal reasons he uses proportional fonts in his code blocks (in his texts) instead of monospaced and the code snippets always look bad. I guess he is stuck in his ways, just have to work around this ugly look.
breppp
Looking at how aesthetically charming the C++ syntax is, I wouldn't expect anything less than Comic Sans code blocks
edflsafoiewq
No, the formatting was definitely botched. It should look much better than it does even in a proportional font.
kstrauser
Agreed. I wouldn't mind if, say, end of line comments weren't perfectly aligned. There's zero indentation so things like
for (string line; getline(is,line); )
s.insert(line);
jcelerier
this is definitely an issue for the editors of the ACM journal
Night_Thastus
That's cursed.
hkwerf
It's typical Stroustrup style to write code in a variable width font. I'd wager they didn't have an option to use a variable-width font in their code blocks in their CMS and normal paragraphs are trimmed automatically.
I didn't see the author at first. However, immediately after seeing the code I checked for the author, because I was sure it was Stroustrup.
edflsafoiewq
The code blocks aren't in a preformatted tag like <pre> so the whitespace gets collapsed. It seems the intention was to turn spaces into but however it was done was messed up because lots of spaces didn't get converted.
maxlybbert
There’s a better formatted PDF on Stroustrup’s website: https://stroustrup.com/21st-Century-C++.pdf .
speerer
This doesn't seem to be a code blog, but a general science communication blog. The editors may not be familiar with code syntax, and may simply be using a content management system and copy-pasting from source material.
mmoskal
> ACM, the Association for Computing Machinery, is the world's largest educational and scientific society, uniting computing educators, researchers and professionals to inspire dialogue, share resources and address the field's challenges.
Most of programming language conferences are organized by ACM.
Cieric
Firefox reader view seems to be a slight improvement since it removes the random right alignments in the article.
kanbankaren
Yeah. Looks nasty. Don't the editors of the ACM have a say on how the article is presented?
modernerd
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.
bb88
The problem with 45 years of C++ is that different eras used different features. If you have 3 million lines of C++ code written in the 1990's that still compiles and works today, should you use new 202x C++ features?
I still feel the sting of being bit by C++ features from the 1990s that turned out to be footguns.
Honestly, I kinda like the idea of "wrapper" languages. Typescript/Kotlin/Carbon.
kstrauser
I'm curious about that now, too. Is there the equivalent of Python's ruff or Rust's cargo clippy that can call out code that is legal and well-formed but could be better expressed another way?
bluGill
Clang-tidy can rewrite some old code to better. However there is a lot of working code from the 1990s that cannot be automatically rewritten to a new style. Which is what makes adding tooling hard - somehow you need to figure out what code should follow the new style and what is the old style and updating to modern would be too expensive.
jjmarr
Modules sound cool for compile time, but do they prevent duplicative template instantiations? Because that's the real performance killer in my experience.
senkora
The best way that I know of to do this is the """ "Manual" export templates """ idea discussed here: http://warp.povusers.org/programming/export_templates.html
(It's a great post in general. N.B. that it's also quite old and export templates have been removed from the standard for quite some time after compiler writers refused to implement them.)
TL;DR: Declare your templates in a header, implement them in a source file, and explicitly instantiate them inside that same source file for every type that you want to be able to use them with. You lose expressiveness but gain compilation speed because the template is guaranteed to be compiled exactly once for each instantiation.
Maxatar
Modules don't treat templates any differently than non-modules so no, they don't prevent duplicate template instantiations.
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