CppCon 2026

Software development has now shifted decisively to a distributed, asynchronous paradigm, in which engineers must manage code that may be executing on parallel threads, or on a different machine. Many mainstream programming languages have adapted themselves to this new world. For example, JavaScript has promises and async/await, Python has asyncio, Rust offers zero-cost async/await with compile-time safety, and Go built goroutines and channels as first-class primitives.

C++ developers face the same challenge but have been left without a standard solution. As a result, much production code remains stuck in “callback hell,” where control flow is inverted, error handling is duplicated at every level, and common patterns like "run A and B in parallel, and then combine results" must be hand-rolled every time.

This is not simply a matter of bolting async/await onto C++. Deterministic destruction, zero-overhead abstraction, and precise control over memory and lifetimes, these very properties making C++ powerful dictate that an async framework cannot rely on a garbage collector or managed runtime to paper over complexity. It must earn its place by working with the language's ownership model, not around it.

std::execution is C++’s answer to this problem. Introduced as part of C++ 26, it solves this through composable senders: lazy, type-safe descriptions of work that can be chained, branched, and parallelized before being submitted to an execution context. Like Swift's structured concurrency, std::execution enforces structured lifetimes so that async work cannot silently outlive its scope.

This talk aims to provide application developers with an introduction to the current proposal and give them a grounding in the fundamentals that can be applied in real-world applications. We will walk through several worked examples: from simple chains to parallel fan-out with error propagation, showing side-by-side comparisons with callback-based equivalents to make the advantages more concrete and relatable.

This talk assumes no knowledge of the std::execution framework and no expertise in async programming, though practical, real-world experience will certainly help ground the examples. Attendees will leave with a working understanding of the sender/receiver model, practical patterns they can use, and a clear picture of what structured concurrency means for C++.

Some of the most expensive C++ bugs are not caused by obscure language features. Instead, they emerge from code that looks reasonable: shared ownership that quietly extends lifetimes, singletons that become invisible dependencies, and performance-driven decisions that harden into architecture.

This talk examines these common design-level failure patterns in large-scale C++ systems. We cover three concrete design shifts:

Lifetimes: Shifting from shared ownership to explicit lifetime boundaries. Coupling: Shifting from implicit global coupling to injected dependencies. Interfaces: Replacing permissive APIs with constrained interfaces using std::span, std::optional, std::variant, and strong types.

Each shift is presented with the failure pattern it addresses, the solution, and the design rule it yields. Attendees will leave with practical heuristics for designing systems that are easier to reason about, test, and evolve: all grounded in real-world failures and the redesigns that fixed them.

For thirty years, SIMD has been the preserve of experts. Writing the fastest C++ has meant hand-written intrinsics, locking code to one architecture, and parallel implementations maintained across every instruction set you ship to. Auto-vectorization can help, but optimizers may give up in complex scenarios where iteration independence isn't obvious. C++26 changes that by putting SIMD in the hands of every C++ programmer, bringing portable, expressive data parallelism into the standard library.

For the engineers who have spent decades writing intrinsics in telecoms, finance, HPC, and embedded systems, migration to std::simd is only worthwhile if it preserves the performance they have fought to achieve. Every cycle counts when code runs tens of thousands of times per second, for years on end, and a portable abstraction that costs ten percent is not a win. The bar for adoption is therefore high: the abstraction must be measurably cheap, the generated code must match hand-written intrinsics, and the tricks and techniques those engineers rely on must all be expressible in the library, not lost in translation.

This talk takes the practitioner's view, aimed squarely at the engineers who write real intrinsics code today and need to know whether std::simd can replace it. It starts with what modern SIMD hardware actually offers, grounding std::simd in real silicon. It then works through the main features of C++26's std::simd with worked examples drawn from the patterns that recur in production intrinsics code, accessible to programmers new to the library and detailed enough for intrinsics veterans to map against their own kernels with all their accumulated tricks and techniques. A look under the hood at our implementation shows how careful API design and aggressive use of hardware features make the abstraction as cheap as the target architecture allows, and how the library fills the gaps on weaker targets with implementations that an expert library author can write once on behalf of every user. The talk closes with a preview of the C++29 proposals being written now to close the remaining gaps, so that std::simd becomes a clear win even for the most performance-critical code.

Application developers sometimes hit a limitation of a 3rd-party library or framework. The Type Erasure design pattern can help us overcome such limitations without the need to change the 3rd-party API.

Type Erasure is a relatively complex design pattern that allows us to treat a set of unrelated classes as if they shared a common base class, while preserving value semantics. The downside is increased code bloat and code complexity as the pattern requires a significant amount of additional code.

There have been quite a few talks explaining HOW to implement Type Erasure, while the topic of WHEN has been rarely discussed. Should we always use type erasure instead of virtual polymorphism? And if not, then what are the criteria?

This talk will show a concrete example from the audio programming industry of how Type Erasure allowed adding new functionalities to the parameter class system of the JUCE C++ framework without changing its API. As such, the talk will be useful for application and library developers who use 3rd party libraries but need an extra degree of flexibility.

You will come out of the talk understanding

• what Type Erasure is,
• when to use it, and
• how to implement it.

You don't need to understand Type Erasure, audio development, or JUCE to attend the talk; the necessary minimum will be explained during the talk.

std::atomic and std::memory_order are utterly opaque abstractions. It feels like they were put in place to hide some monstrosity that is too complex for mortals to comprehend, and inevitably when trying to understand the underlying reality, the explanations end with 'the processor does weird things' and 'think about it as if...'.

Well, 'think about it as if' no more. In this talk we'll present the gory and wonderful mechanics of cache coherence protocols, store buffers, cache invalidation queues and the in-processor load-store-queue. We'll explain how modern hardware design makes different cores have different views of memory, and what fences and read-modify-write instructions do exactly - for both x86/64 and ARM/RISC-V (which are sometimes dramatically different).

This is an advanced low-level talk located at the borderline of software development and electrical engineering, discussing topics rarely - if ever - discussed at C++ conference talks.

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.

Your system has interchangeable strategies chosen at runtime, but the hot path runs millions of times per second. Runtime polymorphism has virtual dispatch overhead. Templates give you performance but lock you at compile time.

This workshop shows how to leverage inheritance for extensibility while avoiding vtable overhead, using a layered architecture of compile-time patterns. We'll build them up through OpenJDK's GC barrier system, where different GC algorithms compose different barriers on one of the hottest paths in the JVM.

We will also discuss trade-offs against alternatives like std::variant, function pointers, and plain virtual dispatch throughout. No JVM knowledge required.

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.

C++20 coroutines come with a reputation for complexity — and writing your own coroutine return type deserves that reputation. But here is the good news: you probably don't have to. With std::generator in C++23, high-quality libraries like Asio and cppcoro today, and std::task on its way in C++26, most developers can simply write co_await and move on.

There is one gap, however. Sooner or later, every developer using coroutines needs to bridge an existing asynchronous interface — a timer, an I/O operation, a thread pool callback, a legacy future — into the coroutine world. That bridge is built with awaiters and awaitables, and that is exactly what this session teaches.

We will start from first principles: what does co await actually do? We will demystify the three functions that form the awaiter protocol — await ready, await suspend, and await resume — and build a clear mental model for each. We will implement a real awaiter from scratch, then explore how symmetric control transfer keeps the call stack flat across deeply chained async operations. Next, we will learn how to make any existing type co await-able without modifying it, using operator co await, and how await transform lets you restrict or adapt awaitable behavior to a specific coroutine context. Finally, we will look at how to write cancellation-aware awaiters using std::stop token, so your coroutines respond promptly when work is no longer needed.

No prior coroutines experience is assumed. If you know what co await looks like on the surface but not what happens underneath it, this session is for you. You will leave with both the knowledge and the code to wrap any asynchronous operation into a first-class co await expression.

In the C++ world, it is often assumed that proper object lifetime management ensures a memory footprint that scales with an application’s actual needs. However, long-running systems are frequently sabotaged by heap pinning: a phenomenon in which Resident Set Size (RSS) refuses to shrink even after significant deallocations. This results in a critical, 'invisible' overhead that defies standard leak-detection tools and can lead to system thrashing and even Out Of Memory (OOM) kills.

Heap pinning occurs when long-lived allocations are interleaved with transient ones, creating a structural barrier that prevents the underlying allocator from releasing memory back to the system. A single persistent allocation can 'pin' an entire block of physical memory, forcing the OS to keep it mapped even if the surrounding space is empty. Consequently, the process footprint reflects historical peak usage rather than the current live state.

In this talk, we will bridge the disconnect between C++ deallocations and physical memory reclamation. You will learn to use allocator-aware objects and std::pmr resources to eliminate pinning by strategically segregating allocations based on their expected lifetimes. We will also demonstrate how to diagnose these 'ghost' overheads when traditional heap profilers fall short. You’ll leave the session equipped to identify and resolve these fragmentation traps, ensuring your application’s memory footprint finally stays proportional to its actual state.

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

For the first time in a generation, the C++ Standards Committee has a new convenor. Meet Guy Davidson.

In the decade since joining the Committee, Guy has not personally authored wording that made it into the Standard. Yet, he exemplifies what the role demands: the ability to work intently, iterate relentlessly, absorb setbacks, adapt, and return stronger. He pairs that with a deep commitment to guiding the evolution of a language that underpins much of the modern world – and a rare talent for setting aside ego to build consensus. Sometimes, he even does it in iambic pentameter; at others, in the rhythm of a sea shanty.

In this fireside chat, Guy will reflect on what it means to inherit an institution, his first months in the role, and the moment 118 hands rose in support of C++26 – while Bjarne Stroustrup’s did not. He’ll also share his own work: projects aimed at expanding C++’s capabilities, including an idea inspired by game engine design that has caught the attention of leading climate scientists.

In C++, monadic operations are a commonly utilized API for interacting with result types like std::optional and std::expected. By chaining the computations, these abstractions allow you to manipulate the underlying values using less boilerplate code. Monadic operations are a powerful tool suitable for a variety of usage scenarios. They enhance code robustness and significantly lower the risk of accidental errors.

Despite its benefits, many users consider the syntax of monadic operations to be overly verbose, and the underlying concept often seems complicated. There are also the cases where the restrictions placed on functions require using extra statements, specific return and arguments types, and reduce code readability. However, are there other options available? Do we have promising alternatives? The short answer is: yes. While C++ does not yet include pattern matching as a native language feature, the standard library still offers tools for achieving many useful pattern-matching-like functionalities. We will explore how to apply std::visit to this problem and evaluate if an abstraction, which we might call std::match, could serve as an effective substitute for monadic operations in various situations.

Based on several years of practical production experience, this talk will explore the use of monadic result type interfaces and comparable alternatives. This information will benefit practicing software engineers looking to deepen their understanding of these features and integrate them into their codebases.

Production C++ code often hides small but deeply complex algorithms inside layers of engineering: APIs, lifetimes, error handling, integration, logging, and glue code. We test classes and systems, but rarely the algorithm itself in isolation.

Off-by-one errors and broken or missing invariants can survive extensive pre-production testing. Line coverage does not imply branch coverage. Branch coverage does not imply coverage of algorithmic corner cases. Testing through a wide public API often obscures the mathematical structure of the problem, making subtle bugs difficult to discover through multiple layers of abstraction.

This talk explores how to extract an "algorithmic core" from a larger component. Its correctness is fundamentally mathematical and largely language-agnostic rather than C++-specific.

Using examples such as substring matching, topological sorting variations, and lazy evaluation on trees, we will examine how problem corner cases differ from implementation corner cases, and how easily some of them are skipped.

We will discuss:

• Recognizing when an algorithm is entangled with boilerplate
• Extracting core logic without introducing accidental complexity
• What it takes to test algorithmic code in isolation
• Raising the level of abstraction to make reasoning easier without merely relocating complexity
• Using LLMs to assist in exploring and validating implementations
• Gradual rollout and comparison of competing implementations

There is no classical treatise on the design and implementation build systems; no faithful textbook every toolchain engineer has on their bookshelf. If there were we would need to throw it out anyway, because C++20 modules required a significant rethink of how build systems orchestrate compilation of C++ software.

It's been said over and over again that C++20 modules complicate the classic compile and link steps for C++. However, few have dived into how exactly build systems are dealing with this step-change in complexity. Talks will demo a few raw compiler invocations and say no more about the subject. This leaves engineers unequipped to deal with problems that arise in their builds; frustrated by opaque error messages and baffling build logs.

In this talk, we're going to fill in the rest of the blanks and explore exactly how build systems are tackling modules.

Are you smarter than a branch predictor? In this interactive, game-show themed session, the audience becomes the branch predictor: participants vote on which of two C++ snippets will run faster before we examine what actually happens on real hardware. The snippets are drawn from real world production code, and correct answers are rewarded with stress balls. Through these examples, we build a practical mental model of how modern CPUs handle control flow, and why even small branching decisions can have a significant impact on performance. A single mispredicted branch can stall a CPU pipeline for dozens of cycles, making control flow a hidden bottleneck in performance-critical systems. Using annotated assembly, performance counter data, and cross-platform comparisons, this talk explores branch prediction, misprediction costs, indirect calls and virtual dispatch, and the trade-offs between branches and conditional moves. We examine how compilers (GCC, Clang, MSVC) transform code under different optimization levels (such as -O2 and -O3), and highlight non-obvious cases where “branchless” code performs worse or behaves differently across architectures. The examples are intentionally small micro-benchmarks, but each exposes patterns that appear in real-world systems when control flow becomes the bottleneck. The session also covers how to design trustworthy micro-benchmarks and validate performance changes using hardware counters. Attendees will leave with a clearer understanding of how branches behave on modern processors, when to rely on compiler optimizations, and when to measure and optimize manually.

C++ Views were introduced with C++20 and extended with C++23 and C++26. They are lightweight objects that specify how to use (specific) elements of collections and their values. By composed into pipelines, programmers can easily define complex processing of collections of data.

However, the use of views also has pitfalls and traps. Therefore you should know about * The consequences of reference semantics * The problems of caching Views * The problems of using const with views * The Filter View Fiasco

This talk gives an overview about both the technology and where to pay special attention.

To navigate safely, a robot must simultaneously ingest high-frequency sensor data, compute complex spatial algorithms, and publish control commands. Historically, frameworks like ROS 2 have handled this via asynchronous callbacks. However, as autonomous stacks scale, relying heavily on unstructured callbacks can obscure control flow, making state synchronization difficult and robust task cancellation notoriously complex.

This talk explores how to transform unstructured, callback-based architectures in a robotics navigation stack into declarative pipelines using structured concurrency (specifically, C++ Senders and Receivers via stdexec). Attendees will dive into two real-world architectural examples: a collision monitor and a waypoint follower, showcasing readable logic pipelines, thread-hopping between an event loop and a static thread pool, and clean task cancellation.

You found the perfect C++ library. But you cannot integrate it with your CMake build without reading three pages of bespoke instructions. The documentation (if any) is a Doxygen-generated API dump. You file a bug, get "read the source," and move on. You never adopted it—and you had every intention of doing so.

Or you are the author of that library. Technically brilliant. Six months after release: three users, no contributors, two support tickets, you are not sure how to answer. Drawing on years of experience as both a maintainer of mp-units — a high-visibility, standards-track C++ library — and as a developer who regularly evaluates and contributes to third-party C++ projects, I have watched this pattern repeat across dozens of technically excellent libraries. The barriers that drive users away, frustrate potential contributors, and quietly kill great projects are predictable. More importantly, they are fixable.

This talk traces the five stages every C++ library must survive — Discovery, Evaluation, Integration, Contribution, and Community — and examines the concrete engineering decisions at each. We will look at how naming, README structure, and CI signals communicate trust to a user who found you three seconds ago; how a properly fuzzed build matrix gives users real confidence across their compiler, their C++ standard, and their platform; how DevContainers and Compiler Explorer eliminate the local setup barrier for both users and contributors; how the Diátaxis framework turns a documentation site from a reference graveyard into a system that serves newcomers, practitioners, and design-curious contributors; and how to craft an AI contribution policy that manages the rising volume of LLM-generated PRs without sacrificing the architectural integrity that makes a library worth contributing to in the first place.

Whether you are a user evaluating libraries, a developer looking for a C++ project worth your time, or an author trying to build one, you will leave with a concrete, field-tested checklist.

Today's world runs on C++. That's because, in domains requiring scale, performance, low latency, and fine-grained control over concurrency, C++ is second to none! Yet in recent years, a growing concern has emerged: C++ programs are often considered unsafe — not because of programmer negligence, but because the language itself provides insufficient mechanisms to prevent or reliably detect undefined behavior (UB).

For those financially and technically invested in C++, its current lack of language safety raises a fundamental question: How can we evolve ISO C++ to be UB-safe without necessarily sacrificing runtime performance, and without breaking backward compatibility with existing, valid C++ code?

In this talk, we begin by motivating an overall approach to UB-safety that starts from a simple but uncompromising premise: each individual potential source of UB must be able to be detected via runtime checking. Crucially, this approach eliminates the notion of "safe" and "unsafe" regions of a program — there is no place where UB can hide, and no need to switch languages, subsets, or tools to achieve comprehensive coverage.

We then examine how the C++26 contracts facility provides the essential foundation for transforming optional runtime checks into the practical, scalable mechanisms to eliminate UB bugs in production software. Contracts give developers fine-grained control over where and when checking occurs, allowing runtime overhead to be spent where it is affordable or most valuable — such as in new, rarely executed, or security-critical code. These decisions naturally evolve over time, as long-running checks that never fire may no longer justify their cost.

Finally, we outline the concrete steps of an incremental journey toward reducing undefined behavior in ISO C++. The result is a model of UB-safety — rooted in C++26 contracts and optional runtime checking — that is competitive with, and in key respects stronger than, approaches taken by other high-performance languages. Most importantly, this model applies not only to new code, but to the vast body of existing C++ software already in the wild.