C:\Users\CppOnline> cd C:\Users\CppOnline\News
C:\Users\CppOnline> runnews
Listing C:\Users\CppOnline\News
Before you can break the rules, you have to know them.
The C++ Standard gives us a beautiful, mathematically rigorous model of concurrency. We are taught that data races are undefined behavior, that atomic operations are indivisible, and that memory barriers stop the compiler and CPU from making a mockery of our logic. We are taught the hierarchy of progress guarantees—how lock-free and wait-free algorithms banish deadlocks, priority inversion, and convoying. By the textbook, lock-free is the obvious tool for high-performance concurrent code.
This morning's talk is the textbook.
This afternoon's talk—"Lock-free programming is dead. Long live lock-free programming!"—is what happens when modern hardware reads the textbook and laughs. To follow that argument, you need the baseline cold. That is what we will build here.
We will start with the distinction that quietly ruins half of all "parallel" code: concurrency vs. parallelism. We will then dig into the C++ memory model and see exactly why your code gets reordered, and how acquire, release, and seq_cst give you the precision to enforce order without overpaying for it. We will dissect std::atomic<T>—what it does, what silently is not (x = x + 1 is not atomic; ++x is), and the mechanics of Compare-And-Swap, including the strong/weak distinction that x86 lets you ignore and ARM emphatically does not. Along the way, we will see how alignment and std::atomic_ref decide whether you get a real hardware atomic or a hidden spinlock the compiler quietly inserts on your behalf. And we will close by connecting the C++ syntax to the silicon underneath—store buffers, out-of-order execution, and the cache coherence machinery that makes all of this work, or appear to.
acquire
release
seq_cst
std::atomic<T>
x = x + 1
++x
std::atomic_ref
This session stands on its own as a rigorous, practical guide to writing correct concurrent C++. But it is also the foundation for the afternoon. Come this morning to learn how concurrent software is supposed to work. Come this afternoon to watch it collide with the silicon.
Any sufficiently advanced technology is indistinguishable from magic. Unfortunately, so is a decent parlor trick. The whole game with AI is figuring out which one you're actually looking at.
Generative AI is changing the programming landscape, which is exciting, confusing, useful, over-hyped, and occasionally just plain scary. For C++ programmers, that mix gets even more interesting because our mistakes are rarely decorative. This talk explores what C++ developers actually need to know about AI: the technical risks, the broader human concerns, and the practical techniques that make these tools more helpful and less hazardous.
We will cover correctness and some issues that are particularly important for C++ code, as well as the bigger questions around trust, skill atrophy, hype, and whether faster code generation is really the same thing as better software. The tone will be practical and interactive, with time for Q&A, discussion, and maybe an impromptu panel if the room has opinions (and for a C++ Now audience, I need to be careful or I may not get to speak past the introduction).
Meeting of the Boost Foundation Board
Join us at the West End Bar for an impromptu reception / happy hour, sponsored by Hudson River Trading.
Asynchronous I/O in C++ has traditionally focused on performing operations such as reads and writes, while the acquisition and release of resources remain fundamentally synchronous. This mismatch becomes increasingly problematic as lower-level mechanisms, such as io_uring, make even the close syscall asynchronous.
While asynchronous functions are well supported by std::execution, C++’s object model remains rooted in synchronous construction and destruction: Constructors and destructors cannot suspend. This raises a fundamental question: How can the deterministic cleanup central to modern C++ be expressed when it may require asynchronous work?
This talk explores a model for asynchronous lifetime management based on scopes. By representing entry and exit as composable asynchronous operations, construction and destruction can be expressed within the same framework as other asynchronous work. The result is a unified approach to resource management, enabling objects whose lifetimes are fully asynchronous while preserving the structure and guarantees of RAII.
The people who bring you C++Now! and the Beman Project talk and answer questions about what they see coming.
We'll also have the closing ceremonies and make announcements about 2027.
Join us for the annual C++Now dinner picnic. If you've travelled with loved ones and/or friends, bring them along!