[HN Gopher] 21st Century C++
___________________________________________________________________
21st Century C++
Author : steveklabnik
Score : 64 points
Date : 2025-02-05 18:13 UTC (4 hours ago)
(HTM) web link (cacm.acm.org)
(TXT) w3m dump (cacm.acm.org)
| Night_Thastus wrote:
| 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.
| Cieric wrote:
| Firefox reader view seems to be a slight improvement since it
| removes the random right alignments in the article.
| npalli wrote:
| 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 wrote:
| Looking at how aesthetically charming the C++ syntax is, I
| wouldn't expect anything less than Comic Sans code blocks
| edflsafoiewq wrote:
| No, the formatting was definitely botched. It should look
| much better than it does even in a proportional font.
| kstrauser wrote:
| 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);
|
| are hard to visually parse.
| adrian_b wrote:
| This must depend on some settings of the browser and
| perhaps also on the locally installed typefaces.
|
| On my Firefox on Linux, this HTML page is not rendered
| with any custom typefaces, but it uses those specified by
| me as defaults for serif/sans serif/monospace.
|
| The C++ code is rendered in my browser with my default,
| i.e. with JetBrains Mono and there is nothing weird.
|
| The code quoted by you is indented as expected, not as in
| your posting.
|
| On my computer, I have mostly typefaces that I have
| bought myself and which are seldom encountered in most
| computers. I do not have any of the typefaces that are
| typically specified in CSS rules, i.e. none of the
| typefaces that can be found in default installations of
| Windows, Linux or MacOS.
|
| So perhaps there is a bug in their CSS at the definition
| of "wp-block-code", which on other computers selects a
| bad typeface that is proportional, so that the narrow
| spaces make the indentation disappear. (Their wp-block-
| code says "font-family:inherit" and I have not searched
| further to see from where the wrong font-family may be
| inherited.)
|
| Here, perhaps because that bad typeface cannot be found,
| the browser uses my default monospace font and the code
| is displayed fine.
| jcelerier wrote:
| this is definitely an issue for the editors of the ACM
| journal
| James_K wrote:
| > This is a Bjarne issue.
|
| I have come to find this category of error to be
| distressingly large.
| hkwerf wrote:
| 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.
| tialaramex wrote:
| The other give away is that he wants to use his awful "I/O
| streams" feature even though he also wants very modern
| features like modules.
|
| Normal people who have a modern environment would
| std::println but Bjarne insists on using the I/O streams from
| last century instead
| edflsafoiewq wrote:
| 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.
| kanbankaren wrote:
| Yeah. Looks nasty. Don't the editors of the ACM have a say on
| how the article is presented?
| speerer wrote:
| 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 wrote:
| > 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.
| maxlybbert wrote:
| There's a better formatted PDF on Stroustrup's website:
| https://stroustrup.com/21st-Century-C++.pdf .
| Night_Thastus wrote:
| That is massively better, thank you!
| jjmarr wrote:
| Modules sound cool for compile time, but do they prevent
| duplicative template instantiations? Because that's the real
| performance killer in my experience.
| Maxatar wrote:
| Modules don't treat templates any differently than non-modules
| so no, they don't prevent duplicate template instantiations.
| senkora wrote:
| 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.
| senkora wrote:
| > You lose expressiveness
|
| Or more, correctly, the following happens:
|
| 1. You gain the ability to use the compilation unit's
| anonymous namespace instead of a detail namespace, so there
| is better encapsulation of implementation details. The post
| author stresses this as the actual benefit of export
| templates, rather than compile times.
|
| 2. You lose the ability to instantiate the template for
| arbitrary types, so this is probably a no-go for libraries.
|
| 3. Your template is guaranteed to be compiled exactly once
| for each explicit instantiation. (Which was never actually
| guaranteed for real export templates).
| jcranmer wrote:
| You can declare a template in a header file, and only provide
| its definition (and hence expansion) in a source file. See
| for example Firefox doing this for its string implementation
| here: https://searchfox.org/mozilla-
| central/source/xpcom/string/ns... (extern template
| declarations are at the end of the header file, and the
| actual template definitions are in
| https://searchfox.org/mozilla-
| central/source/xpcom/string/ns...).
|
| Which is to say, "extern template" is a thing that exists,
| that works, and can be used to do what you want to do in many
| cases.
|
| The "export template" feature was removed from the language
| because only one implementer (EDG) managed to implement them,
| and in the process discovered that a) this one feature was
| responsible for all of their schedule misses, b) the feature
| was far too annoying to actually implement, and c) when
| actually implemented, it didn't actually solve any of the
| problems. In short, when they were asked for advice on
| implementing export, all the engineers unanimously replied:
| "don't". (See https://www.open-
| std.org/jtc1/sc22/wg21/docs/papers/2003/n14... for more
| details).
| modernerd wrote:
| 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.
| kstrauser wrote:
| 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 wrote:
| 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.
| bb88 wrote:
| 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.
| einpoklum wrote:
| > _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_
|
| Well, first, the language can't provide tooling: C++ is defined
| formally, not through tools; and tools are not part of the
| standard. This is unlike, say, Rust, where IIANM - so far, Rust
| has been what the Rust compiler accepts.
|
| But it's not just that. C++ design principles/goals include:
|
| * multi-paradigmatism;
|
| * good backwards compatibility;
|
| * "don't pay for what you don't use"
|
| and all of these in combination prevent baking in almost
| anything: It will either break existing code; or force you to
| program a certain way, while legitimate alternatives exist; or
| have some overhead, which you may not want to pay necessarily.
|
| And yet - there are attempts to "square the circle". An example
| is Herb Sutter's initiative, cppfront, whose approach is to
| take in an arguably nicer/better/easier/safer syntax, and
| transpile it into C++ :
|
| https://github.com/hsutter/cppfront/
| coffeeaddict1 wrote:
| 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
| bluGill wrote:
| 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.
| tialaramex wrote:
| Changes which re-define the language to have less UB will
| help you if you want safety/ correctness and are willing to
| do some work to bring that code to the newer language. An
| example would be the initialization rules in (draft) C++ 26.
| Historically C++ was OK with you just forgetting to
| initialize a primitive before using it, that's Undefined
| Behaviour in the language so... if that happens too bad all
| bets are off. In C++ 26 that will be Erroneous Behaviour and
| there's some value in the variable, it's not always
| guaranteed to be valid (which can be a problem for say,
| booleans or pointers) but just looking at the value is no
| longer UB and if you forgot to initialize say an int, or a
| char, that's fine since any possible bit sequence is valid,
| what you did was an error, but it's not necessarily fatal.
|
| If you're not willing to do _any_ work then you 're just
| stuck, nobody can help you, magic "profiles" don't help
| either.
|
| But, if you're willing to do work, why stop at profiles? Now
| we're talking about a price and I don't believe that somehow
| the minimum assignable budget is > $1Bn
| bluGill wrote:
| The first part is why I'm excited for future C++ - they are
| making things better.
|
| The reason I life profiles is they are not all or nothing.
| I can put them in new code only, or maybe a single file
| that I'm willing to take the time to refactor. Or at least
| so I hope, it remains to be seen if that is how they work
| out. I've been trying to figure out how to make rust fit
| in, but std::vector<SomeVirtualInterface> is a real pain to
| wrap into rust and so far I haven't managed to get anything
| done there.
|
| The $1 billion is realistic - this project was a rewrite of
| a previous product that became unmaintainable and inflation
| adjusted the cost was $1 billion. You can maybe adjust that
| down a little if we are more productive, but not much. You
| can adjust it down a lot if you can come up with a way to
| keep our existing C++ and just extend new features and fix
| the old code only where it really is a problem. The code we
| have written in C++98 (because that was all we had in 2010)
| still compiles with the latest C++23 compiler and since
| there are no know bugs it isn't worth updating that code to
| the latest standards even though it would be a lot easier
| to maintain (which we never do) if we did.
| zozbot234 wrote:
| > I can put them in new code only, or maybe a single file
| that I'm willing to take the time to refactor.
|
| It's also expected that you'll be able to do this with
| Safe C++. Of course the interop with older C++ code will
| then still involve unsafety. But incremental improvement
| should be possible.
| zozbot234 wrote:
| > 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 wrote:
| I have seen 3 different safe c++ proposals (most are not
| papers yet, but they are serious efforts to show what safe
| c++ could look like). However there is a tradeoff here. the
| full bower checker in C++ approach is incompatible with all
| current C+++ and so adopting it is about as difficult is
| rewriting all your code in some other language. The other
| proposals are not as safe, but have different levels of you
| can use this with your existing code. All are not ready to
| get added to C++, but they all provide something better and
| I'm hopeful that something gets into C++ (though probably not
| before C++32)
| Maxatar wrote:
| >the full bower checker in C++ approach is incompatible
| with all current C++
|
| Circle is an implementation of C++ that includes a borrow
| checker and is 100% backwards compatible with C++:
|
| https://www.circle-lang.org/site/index.html
| htfy96 wrote:
| While I sort of agree on the complaint, personally I think the
| best spot of C++ in this ecosystem is still on great backward-
| compatibility and marginal safety improvements.
|
| I would never expect our 10M+ LOC performance-sensive C++ code
| base to be formally memory safe, but so far only C++ allowed us
| to maintain it for 15 years with partial refactor and minimal
| upgrade pain.
| IshKebab wrote:
| I think at least Go and Java have as good backwards
| compatibility as C++.
|
| Most languages take backwards compatibility very seriously.
| It was quite a surprise to me when Python broke so much code
| with the 3.12 release. I think it's the exception.
| skywal_l wrote:
| I hoped Sean would open source Circle. It seemed promising, but
| it's been years and don't see any tangible progress. Maybe I am
| not looking hard enough?
| janice1999 wrote:
| I think Carbon is more promising to be honest. They are
| aiming for something production-ready in 2027.
| menaerus wrote:
| Language is improving (?), although IME it went besides the
| point I'm finding new features to be less useful for every day
| code. I'm perfectly happy with C++17/20 for 99% of the code I
| write. And keeping the backwards compatibility for most of the
| real-world software is a feature not a bug, ok? Breaking it
| would actually make me go away from the language.
| pjmlp wrote:
| Clion, clang tidy and Visual C++ analysers do have partial
| support for the Core Guidelines, and they can be enforced.
|
| Granted, it is only those that can be machine verified.
|
| Office is using C++20 modules in production, Vulkan also has a
| modules version.
| James_K wrote:
| Sincerely, fuck this. There are a million less stupid things you
| could do than spend decades trying to rip out every C part of C++
| and replace it with some shiny new widget that inevitably blows
| even more crap up. Between Rust and Zig, the problems of C++ have
| been solved much more elegantly and it's time to consign it to
| the trash pile of history.
|
| As a programmer, I find C++ deeply offensive. It is so
| objectively horrible in every capacity, but it still somehow
| managed to limp on for all these years and cause endless torture
| to its users. It's disgraceful that this has been allowed to
| happen. Like watching those decaying US politicians publicly
| break down while the hawks circle waiting for them to drop.
| SirHumphrey wrote:
| Even Cobol code hasn't been ported in it's entirety, and the
| whole codebase at the peak was probably orders of magnitude
| smaller than C++. It's also far easier to port Cobol - with it
| being used mostly for data processing and business logic - than
| C++ that was used for all manners of strange, esoteric and
| complicated pieces of software requiring thousand to millions
| of man-hours to port (for example most of Gecko and Blink).
|
| C++ will be here forever, at least in some manner.
|
| edit: spelling
| einpoklum wrote:
| > Between Rust and Zig, the problems of C++ have been solved
| much more elegantly
|
| Those languages occupy different points in the design space
| than C++. And thus, in the general sense, neither of them, nor
| their combination, is "C++ with the problems solved". I know
| very little Rust and even less Zig. But I do know that there
| are various complaints about Rust, which are different than the
| kinds of complaints you get about C++ - not because Rust is
| bad, just because it's different in significant ways.
|
| > It is so objectively horrible in every capacity
|
| Oh, come now. You do protest too much... yes, it has a lot of
| warts. And it keeps them, since almost nothing is ever removed
| from the language. And still, it is not difficult to write very
| nice, readable, efficient, and safe C++ code.
| spacechild1 wrote:
| > It is so objectively horrible in every capacity,
|
| Total hyperbole and simply not true.
|
| > but it still somehow managed to limp on for all these years
|
| Before Rust became somewhat popular, there was simply no
| serious alternative to C++ in many domains.
| pjmlp wrote:
| Start by removing Rust's dependency in GCC and LLVM, both
| written in C++.
| tialaramex wrote:
| Rust doesn't "depend" on LLVM in the sense you seem to
| imagine, you can instead lower Rust's MIR into Cranelift
| (which is written in Rust) if you want for example.
|
| LLVM's optimiser is more powerful, and it handles unwinding,
| so today most people want LLVM but actually I think LLVM's
| future might involve more Rust.
| crims0n wrote:
| 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?
| IshKebab wrote:
| Depends exactly what you want to do. C is not very popular at
| all in professional settings - C++ is _far_ more popular. I
| would say if you know Rust then C++ isn 't very hard though.
| You'll write better C++ code too because you'll naturally keep
| the good habits that the Rust compiler enforces and the C++
| compiler doesn't.
| pjmlp wrote:
| The only places where C++ failed to take C's crown has been on
| UNIX clones (naturally, due to the symbiotic relationship), and
| embedded where even modern C couldn't replace C89 + compiler
| extensions from the chip vendor, many shops are stuck in the
| past, even though most toolchains are already up to C++20 and
| C17 nowadays.
|
| Rust is still too new for many folks to adopt, it depends on
| how much you would be willing to help grow the ecosystem,
| versus doing the actual application.
|
| It will eventually get there, but also have the same issues as
| C++, regarding taking over C in UNIX/POSIX and embedded, and
| C++ has the advantage of having been a kind of Typescript for
| C, in terms of adoption effort, being a UNIX language from
| AT&T, designed to fit into C ecosystem.
| tialaramex wrote:
| 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.
___________________________________________________________________
(page generated 2025-02-05 23:01 UTC)