CppCon 2026

How far can C++26 reflection take us? What are some techniques, gotchas, limitations and workarounds? How would reflection help write code that interacts with bespoke binary data formats? Come along as we explore a practical example together.

This talk will review advice gleaned from applying C++26 reflection to binary (structs on a wire) protocol handling. This type of protocol exists all around the world from financial market data formats to custom hardware interaction. Is the proposed reflection support enough to take a protocol definition written in the native terms of C++ and create flexible components to interact with that protocol?

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.

Starting from the simple objective of writing an optimized lexer we will grapple with their fundamental performance factor: branch prediction. We will investigate how lookup tables can improve (or hurt) the CPUs prediction capabilities with some unexpected results. Over time our design evolves by combining parsing and lexing into a single step in a way that is as fast as just a standalone lexer. A central aspect of the design will be a primitive parsing state machine from which the parser source code is generated.

After the talk attendees will have a better understanding of some advanced branch prediction techniques and should have some new ideas for their present or future parsing endeavors.

Modern C++ development involves much more than compiling source files. Cross-platform builds, dependency management, C++ modules, package metadata, SBOM generation, CI infrastructure, and distributed builds have all increased the complexity of software engineering over the last two decades.

CMake has evolved alongside those challenges.

This talk explores how modern CMake helps make difficult software-engineering problems more manageable through targets, dependency modeling, metadata generation, debugging tools, and scalable build orchestration.

We will examine how CMake supports C++20 modules, including dynamic dependency scanning, build graph updates, and import std.

We will also look at CPS and SBOM generation together: CPS provides machine-readable package metadata, while SBOM support helps CMake expose software supply-chain information from the dependency graph.

Next, we will discuss debugging CMake itself using the CMake debugger protocol, and debugging builds using the CMake Instrumentation API to understand where time is spent during configuration and build execution.

Finally, we will examine distributed execution and build acceleration, exploring options available to CMake users in both open-source and commercial environments.

Along the way, we will discuss the real-world challenges, trade-offs, and lessons learned from evolving a long-lived build system to meet the demands of modern C++ development.

This is not your mother’s CMake.