CppCon 2026

Native C++ types often become the format for bytes that cross a boundary: shared-memory IPC, plugin interfaces, persistent storage, or software built for more than one ABI. At that point the type is no longer just an implementation detail; it is part of a binary contract. trivially_copyable , sizeof , and code review help, but they do not answer the two questions that matter: may this type be transported as bytes at all, and do all supported ABIs give it the same object representation?

C++26 reflection can derive that evidence from the type itself. The technique builds a compile-time layout signature from ordinary C++ types, without IDL, generated stubs, or runtime inspection. The signature records the representation facts needed for byte transfer: architecture and endianness, leaf type tokens, sizes, alignments, absolute offsets, bit-fields, and pointer-like markers. It deliberately leaves out field names and source-level meaning.

With those signatures in hand, the build can enforce a gate for memcpy-style transfer. You name the boundary types and supported ABIs. Each target exports signatures, and a verification build permits direct byte transfer only when the type is byte-copy safe and the signature matches across the set. We'll walk through the workflow with static_assert checks and CI diagnostics: a fixed-width type that passes, a pointer-containing type rejected by admission, and a platform-divergent type rejected by signature comparison. The claim is intentionally narrow: representation compatibility, not semantic compatibility or schema evolution.

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.

Every Boost library that graduated to the C++ Standard became invisible. shared_ptr doesn't say "Boost" anywhere. Boost's greatest successes carry no signature, and that invisibility is killing recruitment. This talk is not a status report. It is an answer to the question: why would I give my best work to a project that erases my name?

We begin with the people. Peter Dimov. Howard Hinnant. Marshall Clow. Beman Dawes. These engineers didn't just write libraries, they defined what production-quality C++ means. We will say their names, show their faces, and then ask the only question that matters for Boost's future: who replaces them? Every technical detail in this talk serves that question.

The answer starts with the peer review process, not as a quality gate, but as an apprenticeship. Boost review doesn't just catch bugs; it forges people. It is the mechanism by which a competent developer becomes a Dimov-class designer, and we will show how that pipeline works today.

Then the technical core. Boost.Unordered's unordered flat map. Joaquín López Muñoz sat down, studied SIMD probing, and built something faster than a team at Google. Boost.Intrusive — presented as a magic trick before an explanation. One object, three containers, and zero extra allocations. Boost.Decimal, IEEE 754 decimal floating-point that feels like a native type, with portable performance rivaling GCC's non-portable _Decimal extensions. We will also survey other recent additions.

Networking gets its own act. Beast, Corosio, Capy are a statement of intent: Boost is building the networking layer the committee has been unable to standardize for fifteen years, and we believe we can ship it. We will show how buffer sequences, stream concepts, and type-erased I/O deliver ABI-stable networking compiled once against an abstract transport.

We spend some time with related C++ Alliance initiatives to make the ecosystem safer and more robust. And a quick mention of the upcoming Boost Documentary.

We close not with a mailing list URL but with a name. One person, a contributor who used Boost for a decade, then brought their own work, took the reviews, and was mentored. They now help maintain Boost. A person is a door; a URL is a wall. The thesis of this talk is not "Boost is alive." The thesis is that Boost is where you become the engineer you want to be. And every section, from the review process to the mentorship lineage to the fact that one person can build the fastest hash map in the industry, is proof.

Compiler Explorer looks simple: type code, get assembly. Underneath: a fleet of sandboxed machines running hundreds of compilers across dozens of languages, terabytes of binaries to keep current, and the ongoing problem of executing arbitrary code from internet strangers.

A lot has changed in the 14 years that the site has been around: The sandboxing layers that let it run other people's code without losing sleep. The storage situation that very nearly broke it, and the content-addressable filesystem that quietly rescued everything. The operational war stories, the migration sagas, and the bits that are far more boring than they look from the outside. Along the way you'll see some of CE's recent features in their natural habitat, and get a peek at what's coming next.

You'll come away with a working mental model of how to run untrusted compilation at scale - and why the parts that look easy are almost always the hard ones.

C++20 modules are finally usable end to end, from your own modules to 'import std;' The functional build-system support with real diagnostics. This talk teaches modules the way #include was once taught: with small files, a build, and concrete use cases. Modules stopped being experimental somewhere around 2025. This session builds the mental model from scratch: what a primary module interface unit is, how partitions and implementation units fit together, and, crucially, how import differs from #include in ways that matter day to day. It uses a small library, exposes it as a module, splits it across partitions, consumes import std; and observes the compile-time effect. Then it answers the questions every team hits in week one: how modules interact with macros, with templates in headers, with header-only dependencies, and with a mixed codebase that can't convert everything at once. The examples will be using CMake, clang and recent gcc. You will leave able to structure a small library as a module, explain why a macro didn't cross a module boundary, and plan an incremental adoption that doesn't require converting the whole tree.

Last year, the title of this talk would have been "AI in a C++ World." That it isn't anymore tells you most of what changed.

A year ago, AI was the visitor we were evaluating. Now, it is the room we work inside, and the question for C++ programmers is no longer whether to take the technology seriously but how to keep doing serious work in its presence.

Another year of using these tools in earnest on production C++ has clarified what works, and given me an actual workflow to point at instead of a set of slogans.

I'm a professional C++ developer, and yet I haven't written a line of code since last November. Not because I've not written any code, but because AI has written every line.

It is not a theoretical presentation, but a working practitioner's report. I'll walk you through the development workflow I now use for serious C++ development.

Along the way I'll cover what C++ developers actually need to know about how LLMs work, what the agentic loop is, and how to get production-quality C++ out of these systems. The tone is practical, but opinionated, though those opinions are based on personal experience.

If you are not yet using AI as another independent member of your development team, or if you think I'm completely off my rocker, then this talk is definitely for you.

Applications that present rapidly changing market data to human users face a practical challenge: updates may arrive thousands of times per second, but humans only benefit from periodic refreshes. Efficiently coalescing and scheduling that work without overwhelming CPU resources becomes a concurrency problem rather than simply a rendering problem.

This talk demonstrates how modern C++ atomics can be used to build a lock-free timer scheduler optimized for extremely high update rates. The scheduler follows a single-producer, multiple-consumer design in which work items represent recurring tasks that must execute periodically. Consumers process scheduled work and re-schedule it for future execution without relying on traditional locks or centralized coordination.

The most unusual aspect of the design is its “reverse work stealing” behavior: consumers can proactively give away work to other consumers and become idle themselves. Rather than distributing work evenly across all threads, the scheduler attempts to pack work onto as few cores as possible, reducing idle spinning, lowering CPU utilization, and improving cache locality. Because tasks may have highly variable execution times, the scheduler must also prevent pathological cases where work is endlessly redistributed between consumers.

Attendees will learn how atomics, lock-free forward lists, and memory ordering can be combined to implement high-throughput schedulers with predictable latency characteristics. The talk also discusses practical tradeoffs, implementation challenges, and performance measurements from production-inspired workloads, including producer throughput of approximately 50 million scheduled tasks per second and consumer processing throughput approaching 700 million tasks per second, while keeping migrated work items below 1% in typical workloads.

Modern coding agents are incredible, but they still struggle with the kind of large, unstructured codebases that are common in C++. There are several techniques and tools that can make them perform much better. Here we show examples and demos of how to get your agent to work better with complex code. The focus is on providing an overview on current techniques and how we’ve found they work best. - Skills, memory and MCP - these have all been hyped hard, we’ll sort through where they are actually useful. - All agents (Claude, Copilot, Codex, Gemini) support these - some better than others. - What a skill is and what it isn’t - How to use persistent memory - Why MCP servers are still needed (but not always) - Context engineering. - Context management keeps changing - we’ve got autocompaction and 1M token windows now, why should we care anymore? - When to “manage” your agent’s context window and when it’s a bad idea - How to understand where context is being spent. - How and why to use subagents - these are almost always available but the capabilities in different frontends are exposed in different ways. - Spec Oriented Development: buzzword, euphemism for vibe coding or the future of programming? - What is it? - What tools exist? Covering options such as SpecKit, Kiro, etc. - Working in parallel with agent teams! - How to get started without having to learn anything (almost)! - Runtime context. - How to give your agent the best possible feedback path so you can stop micromanaging it and leave it to complete longer, more complex tasks. - Techniques including testing, CI integration and recording-based technology