CppCon 2026

This talk is the 2026 edition of our series that highlights low-latency, networking, parallelism, and concurrency proposals to the C++ Standards Committee, especially those discussed in the Kona 2025, Croydon 2026, and Brno 2026 meetings. This talk from the Concurrency TS2 Editors, DG and SG14/19 chair will describe the following features and show how they can be used. It will also give their motivation, background, and their place within the overall framework of C++ low latency, networking, parallelism and concurrency:

Atomic Compare and Hazard Pointers Reclamation Control

• We discuss a proposal for atomic compare operations that clarify programmer intent and simplify static analysis by avoiding the unnecessary leakage of atomic values. We also explore how these operations complement recent proposals to enhance the expressiveness of atomics, such as the use of tagged pointers.
• We examine techniques for controlling C++26 hazard pointer reclamation, demonstrating how to offload retirement overhead to asynchronous executors to ensure predictable thread latency. We show how this capability can prevent specific deadlock scenarios and assess whether such controllers should be standardized or remain user-space patterns.

Twenty-One Years Without Sockets, The History of Networking in C++ and What We Learned Along the Way

• Go has standard networking. Rust has standard networking. C++ has been trying since 2005. This talk tells the twenty-one-year story in seventeen minutes: the library that shipped but never standardized, the dependency that blocked it, the coroutine revolution that changed the assumptions, the technical discovery that explains why I/O doesn‚Äôt fit the three-channel model cleanly, and the bridge that lets both models win. Three decision points, three lessons, one live question: how should coroutines and senders coexist for C++29? No villains. Just the story and the engineering. Networking is now finally a C++29 priority, so said the Direction Group‚Äôs P5000.

Out-of-Thin-Air (OOTA) Values.

• The memory models for high-level languages, including C++, C, Rust, and even Java, have been prone to out-of-thin-air values. For example, given two atomic integers X and Y, both initially zero, if one thread does a relaxed assignment from X to Y and the other does a relaxed assignment from Y to X, the mathematical C++ memory model does not rule out the outcome where both X and Y have the value 42. However, both communication and computation take time, and so we have proven that OOTA values cannot happen on real-world production-quality computer systems. This result makes compiler-writers‚Äô lives easier, and also eases the jobs of those brave individuals pursuing the full mathematical OOTA problem by relieving them of the need to live within CPU and memory constraints of production-quality compilers.

Discussion

There are other features under discussion, but the features we will present seem close to approval, are particularly interesting, and/or are relatively non-controversial. We will show use cases for each and prognosticate their journeys to C++26 and beyond. This will help programmers in concurrency, lock-free programming, and low-latency applications understand how best to take advantage of each of these important facilities.

What makes an async workflow readable? Not just linear control flow — you also need to see where errors go, what each step depends on, and how failures compose. This talk takes a single production workflow — multiple async RPC calls with conditional branching, parallel fan-out, and partial-failure handling — and shows it implemented in three paradigms: callbacks with thread pools, a workflow orchestration graph over futures, and coroutines with std::expected. We evaluate each through four questions: where does the control flow live, the error flow, the coupling, and the migration risk?

Coroutines restore linear control flow, but without structured error composition, the workflow drowns in manual failure checks at every step, that is more error-handling code than business logic. Task

Sean Parent's "no raw pointers" guideline is often misunderstood as "avoid T* , use smart pointers instead", even though Sean explicitly included smart pointers in his definition of a raw pointer: "anything with implied ownership and reference semantics".

This talk presents a refinement of that guideline:

Pointers - smart or not - shall not appear in function signatures, neither as argument nor as return type.

The focus of this talk is how to implement classes as regular types while still supporting dynamic allocation, polymorphism, and sharing internally.

It shows how such value types can be implemented manually, without dedicated library support. It then follows the evolution of the language and library in gradually simplifying these abstractions: C++11 smart pointers ( unique_ptr and shared_ptr ), C++26 vocabulary types ( indirect and polymorphic ), as well as in-progress proposals ( copy_on_write and protocol ) are presented as tools to simplify writing safe abstractions, not as safe abstractions themselves.

Along the way, the talk revisits the Rules of 3/5/0, exception safety guidelines, const propagation, aliasing, and local reasoning.

The talk aims to make you stop passing pointers around.

Time handling in C++ looks simple — but it has some caveats. Between system_clock , steady_clock , high_resolution_clock , and a few new friends from C++20, it’s easy to pick the wrong one and end up with flaky tests, wrong timestamps, or confusing results.

This talk demystifies how time works in C++. We’ll explore what a "clock" really is, how std::chrono models it, and why not all clocks tick the same way. You'll learn when to use each standard clock, how to reason about monotonicity and precision, and how to build your own custom or fake clocks to make testing reliable.

By the end, you'll not only understand the difference between wall time and steady time — you'll know how to use them confidently in your production and test code.