153. Carbon, WG21, ABI, Books, Build, Packages




Powered by RedCircle

WG21 August mailing


From an earlier mailing:

  • P2547R1 Language Support for Customisable Functions by Lewis Baker – seeks to improve over existing customisation-point mechanisms in a number of ways, including introducing a new keyword customisable for namespace-level functions and function templates that can be overridden, and can also be final and have a default implementation. This makes using customisation point objects easier than ADL- or tag_invoke-based customisation solutions.

Jason Turner on C++

Jason Turner tweeted:

Theory: every aspect of modern technology hinges on C++

Evidence: JavaScript engines, browsers, Windows, KDE, JVM all written in C++. Python is C, but all major libraries are written in C++.

GTK on Linux? Your C compiler is written in C++.

Also: Adobe tool suite, OpenOffice and Microsoft Office are written in C++

Rust programmer? You rely on LLVM which is written in C++

If we want to (go) even deeper, it’s no secret that the main lithography machines used to actually create our CPUs run software written in… you guessed it! C++!

Many embedded developers are moving to C++.

If you use an IDE it’s either written in C++, or relies on software written in C++.

Once GCC moved to C++, I think C++ became unavoidable in your ecosystem.

That’s a little dose of C++ optimism for you in case you need it after the previous meeting.

Carbon reactions

ADSP Podcast Episode 89: The Carbon Programming Language (Part 2)


The current Carbon core team – Chandler Carruth, Kate Gregory, and Richard Smith – are not “benevolent dictators for life”, there will be rotation.

And that was it for Carbon language in this episode.

C++ Syntax Sucks and Carbon Fixes It

Erik Engheim, a C++ developer from Norway, wrote an article called C++ Syntax Sucks and Carbon Fixes It on his Medium blog (please don’t use Medium, it hides your content behind a paywall).

A better title would be C++ Syntax is Hard to Parse and Carbon Syntax Is A Bit Simpler, but it’s not as clickbaity.

The author quotes Jeffrey Hykin, the author of VSCode C++ highlighter plugin, who says:

The C++ syntax highlighter, at 19,000 lines, is not only the largest of any language but nearly four times larger than the 2nd largest syntax (Typescript at 5,000 lines).

The author writes:

The problem with C/C++ syntax is that you cannot determine what a statement is until you have parsed several tokens.

Ah, the famous programming language C/C++.

He mentions ’the most vexing parse’ where you can’t easily distinguish between a function and a variable declaration:

1int bar(int(x));

It’s not an issue in Carbon because Carbon classes don’t have constructors, and objects are initialised using assignment.

Erik writes:

One of the most annoying things when writing C++ code is dealing with const correctness and references.

He likes the fact that in Carbon the compiler takes care of choosing the best way to pass parameters to a function, so the programmer doesn’t have to think about it. I have a suspicion that we’ll end up having to know what the compiler chooses to represent parameters, and thus go back to the C++ situation, only even more confusing.

Erik really likes introducer keywords in Carbon. He says:

This makes scanning a list of functions or methods quicker in Carbon. Especially languages, such as Java, are terrible in this regard. You read public static void, and then you finally get to the important part, which is the method name. C++ is better, but still take focus away from method names by having info about the return values come before the method name.

He says nothing about the modern function declaration syntax in C++ using auto, which I’m sure he knows about, but chooses to omit because it’s inconvenient for the point he is making. Hmm…

To summarise the article, Carbon doesn’t ‘improve’ C++ syntax but chooses to be different, and that’s OK. Yes, C++ syntax is hard to parse, but on the other hand Carbon barely exists at the moment (to the point that Erik had to make assumptions on how it may look based on Rust and Go) and doesn’t even have a proper compiler yet. We’ll see how Carbon syntax develops.

The Reddit thread is here. Some quotes:

They just wanted the parser to be easier. Most of the syntax is worst for users #

Agreed. Maybe it solved some fringe cases, but for 90% of the usage it looks like the syntax has more noise and is harder to read. #

As of C++11, there is the auto keyword, alternative function syntax and aggregate initializers. When you use those, it makes the syntax look a lot like Carbon #

I’ve seen people actually ask “should I learn C++ still, or is it inevitably dying because of Carbon”? And it’s just the silliest thing to even suggest #

It’s absolutely a control thing. The rest of the C++ standards committee voted against something the Google reps wanted, and they took their toys and went home. Now there’s Carbon. #

Given that Carbon was started because, by all appearances, Google lost a single vote in the c++ community and decided to not try again or convince people and reach consensus, but rather hard fork…what will they do in the future if the Carbon community votes against them on some issue? Or is the intention that this is a forever Google dominated project? #

Is it too late to break ABI?


Has the ship sailed? Is C++ doomed or do we have a magic solution in the horizon?

A few years ago C++ voted to put performance and ease of use as second priority over breaking ABI. Google stopped its contributions to C++ and Clang. Today, they announced Carbon. <…>

Do we even intend C++ to keep evolving, or we intend for C++ to follow the C path, and prevent evolution in favor of not breaking anything forever? Will an ABI break ever happen? <…>

A question like this usually results in a thread full of rants and venting. Here is my summary of the points raised:

  • The committee is useless. #
  • Caring so much about ABI cost the Committee contributions of Google employees.
  • Those still using C++98 and old compilers should be disregarded. #
  • Old code doesn’t deserve new compilers.
  • Everybody should compile everything every time from source. #
  • The embedded domain also exists, and compiler upgrade story there is painful. #
  • People are still upset at the C++11 string CoW ABI break. # #
  • People are too obsessed about breaking ABI. It won’t solve C++’s problems. # #
  • Backward compatibility is C++’s strength, not weakness. # #
  • You can just implement your own types. #
  • Epochs would have been great, but are unrelated to ABI. #
  • The Standard Commitee hasn’t banned ABI breaks. What they did however ruled out is introducing changes that mandate them for now. #
  • C++ sucks.
  • C++ is great and is not going away.

Book: Software Engineering at Google

This is the title of the book released by O’Reilly in 2020 and available online if you have an account with them, or you can read it for free on the web. Written by Titus Winters, Tom Manshreck and Hyrum Wright, it is:

<…> about the engineering practices utilized at Google to make their codebase sustainable and healthy.

This book should be useful even if you aren’t trying to get a job at Google.

Reading it online could be tricky though due to Google’s choice of an extremely thin font. They probably thought that software engineering at Google is so difficult that even reading about it should be as hard as possible. You can always use your browser’s reader view, of course.

Elements of Programming

Alexander Stepanov and Paul McJones made their book Elements of Programming freely downloadable as a PDF, go get it – it’s a classic.

From C++98 to C++20

Konstantin Burlachenko wrote a long technical note outlining changes from C++98 to C++20, which can serve as a refresher for C++ developers. Curiously, he included the following explanation:

C/C++. By C/C++, we mean C or C++ programming languages.

Still, seeing C/C++ throughout the document is a bit ugh.

New string functions in C++20 and C++23

A new C++ cheatsheet from Hacking C++ lists string functions introduced in C++20 and C++23.

Other languages are giggling uncontrollably.

Catching sanitizer errors programmatically

Daniel Lemire

1extern "C" {
2void __asan_on_error() {
3  std::cout << "You caused an error: " << message << std::endl;

Synthesizing a C++20 three-way comparison from two-way comparisons

Raymond Chen (Microsoft) wrote an article called How can I synthesize a C++20 three-way comparison from two-way comparisons? where he discusses the new C++20 <=> (‘spaceship’) operator. He presents a useful table that lists comparison outcomes of a spaceship operator, of which there are five (from a ’three-way comparison operator’, which shouldn’t surprise you, a C++ programmer, too much).

  • For strong ordering, the result can be: less, equal, equivalent, greater.
  • For weak ordering, the result can be: less, equivalent, greater.
  • For partial ordering, the result can be: less, equivalent, greater, unordered.

Regarding the difference between ’equal’ and ’equivalent’, Raymond says:

For example, two instances of the same string “hello” are equal, in that they represent the same string and are fully interchangeable. On the other hand, two people with the same security clearance are equivalent from a security perspective (they have access to the same things), but they are not equal (they are nevertheless different people).

Raymond states:

The strong ordering distinguishes between items being equal (identical and interchangeable) and equivalent (not interchangeable but close enough for some purpose).

In the Reddit thread, STL says this is incorrect, as the standard mandates that:

1static_assert(std::strong_ordering::equal == std::strong_ordering::equivalent);

Raymond continues:

Suppose you have an object from a class library that predates C++20 and doesn’t support three-way comparison. You want your code to be able to take advantage of the three-way comparison should the library be updated but fall back to two-way comparison in the meantime. In other words, you want to take advantage of three-way comparison if available.

His advice is to use std::tuple for comparing objects that don’t support equality check and only support operator<:

Tuples have the bonus property of supporting the three-way comparison operator, even if the underlying types do not. In the case where they do not, they will synthesize a three-way comparison from the two-way comparisons.

2compare_3way_via_tuple(T const& a, T const& b)
4    return std::forward_as_tuple(a) <=>
5           std::forward_as_tuple(b);

Note that if the type being compared supports operator== it will be more efficient to use std::compare_weak_order_fallback as it checks for equality first, which is more efficient, and only then falls back to operator<.

Interestingly, STL also says in the thread that in order to use the spaceship operator it is necessary to include the <compare> header, which is a bit weird as now we have an operator (a language feature) that depends on a standard library header.


Visual Studio extension and standalone app for build times and compilation data visualization.


Displays compilation cost inline in source files. Uses either MSVC or Clang -ftime-trace.

Debugging coroutines in Clang 15

There is a new article on the new coroutine debugging facilities in Clang 15. If you’re lucky enough to be able to use it, and are working with coroutines, these features could be very helpful.

Quote from the introduction:

For performance and other architectural reasons, the C++ Coroutines feature in the Clang compiler is implemented in two parts of the compiler. Semantic analysis is performed in Clang, and Coroutine construction and optimization takes place in the LLVM middle-end.

However, this design forces us to generate insufficient debugging information. Typically, the compiler generates debug information in the Clang frontend, as debug information is highly language specific. However, this is not possible for Coroutine frames because the frames are constructed in the LLVM middle-end.

To mitigate this problem, the LLVM middle end attempts to generate some debug information, which is unfortunately incomplete, since much of the language specific information is missing in the middle end.

This document describes how to use this debug information to better debug coroutines.

Lewis Baker on coroutines

Lewis Baker, who wrote a bulk of coroutine code and the helper library cppcoro, tweeted a link to Godbolt containing a heavily commented skeleton code for writing coroutine-based code. As you can see, it’s pretty long, so if you only want to use pre-built coroutine wrapper classes, use cppcoro. But if you need to implement coroutine support from scratch for your own types, this boilerplate code may come handy.

Steve Downey took the code and put it in a buildable CMake project for convenience.

John MacFarlane’s CMake project template


Large project package management


Suggested in the thread:

Bazel or CMake?


Insightful quote:

Our team have a medium sized C++ project that uses Bazel. Managing dependencies is painful, as nearly all third-party C++ libraries use CMake. <…>

Actually our codebase were originally using CMake. But there’s a high-rank manager, who came from Google, that kept saying how great Bazel is, and finally persuaded our tech lead to switch to Bazel.

BTW, the ex-Googler left our company a year ago, and Bazel sticks with us.


Managing dependencies in Bazel has been a lot easier than CMake.


Bazel is a better and more powerful build system overall, is more hermetic, has stronger support for accurate caching and parallel execution, including remote caching and remote execution, and caching and parallel/remote execution of tests <…>

Other quotes in favour of Bazel: # #

Other suggestions:

Boost 1.80

Engine Simulator

Combustion engine simulator that generates realistic audio.


A redditor asks: How to gauge a programmer’s C++ competency?

The first reply is:

Ask them their opinion on the language. If the first thing they do is sigh, they’re probably okay.

Twitter: CPU