CppCon 2026

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.

Modern storage hardware has evolved at a breakneck pace. PCIe Gen 5 NVMe drives can push data at 10 GB/s, yet standard C++ file abstractions often leave them starving for data. Many developers think they need to abandon portability in favor of unmaintainable, OS-specific kernel bypasses to achieve the throughput necessary to saturate these drives. This session is for developers writing high-throughput, performance-critical applications who want to hit bare-metal speeds without sacrificing clean architecture, cross-platform support, or type safety.

Using a high-throughput cryptographic hashing engine as a concrete case study, this presentation demonstrates how to design a hardware-saturating data pipeline built entirely on the idioms of C++26. We will explore how the mathematical design of an algorithm - specifically BLAKE3's binary Merkle tree structure - can be mapped directly to wide SIMD vector lanes and concurrent CPU cores. We will walk through an execution model that completely bypasses the OS page cache, orchestrates memory without heap allocations on the hot path, and unifies OS kernel quirks in a portable way.

By the end of this presentation, you will learn how to replace rigid thread pools with lock-free, asynchronous execution graphs using Sender/Receiver paradigms (std::execution) and vectorization (std::simd). Crucially, we will focus on the build engineering required to make this work today. We will cover how to use advanced CMake tooling to safely compile multi-architecture vector binaries from a single source of truth, how to prevent LTO cross-contamination, and how to structure your pipeline today to seamlessly absorb upcoming C++ features in a world of trailing vendor toolchains.

CUDA Tile C++ is a novel C++ DSL and compiler that automatically parallelizes array operations across GPU threads while presenting a single logical thread to the programmer. In CUDA Tile C++, parallelism is expressed through SIMD-style operations on arrays of data called "tiles" while memory accesses are written using structured memory abstractions. The compiler analyzes the tile and memory operations to generate an equivalent multi-threaded program that leverages the advanced hardware capabilities of modern GPUs. This allows the user to write simple programs that exploit GPU parallelism without needing to manage low level hardware concurrency.

As GPU architectures evolve to meet the demands of high performance computing, the traditional multi-threaded GPU programming model becomes increasingly unwieldy. To achieve optimal performance, the GPU programmer must manage a growing variety of hardware features including shared memory, Tensor Memory Accelerators, and Tensor Cores. Traditional CUDA code is deeply coupled to the underlying hardware resulting in complex and non-portable algorithms. The CUDA Tile C++ compiler removes the need for coordinating these low level hardware details, freeing the user to reason about their algorithm rather than asynchronous code.

The tile programming model introduces three key abstractions:

• cuda::tiles::tile - a multi-dimensional array with value semantics whose operations are parallelized across the GPU
• cuda::tiles::tensor_span - a view into a multi-dimensional in-memory array with an interface similar to std::mdspan
• Tile Views - adapters that present a uniform "chunking" of a tensor_span which gives the compiler visibility into memory access patterns

In this talk, we will explore how these abstractions allow NVIDIA's Tile C++ compiler to schedule the program across hardware threads all while preserving the illusion of a single-threaded abstract machine to the user.

Making native code fast is a team sport: efficient algorithms, high-performance libraries, memory-conscious design, and modern hardware all play a role. But the critical link between your code and the hardware it runs on is the optimizing compiler.

This talk explores new & improved compiler optimizations in Visual Studio 2026, and how these improve the performance of existing C++ code with minimal source changes. We will examine both architecture-independent optimizations (such as improved scalar replacement, vectorization, and loop transformations) and architecture-specific enhancements (such as AVX-512 and NEON specific optimizations). Along the way, we will connect high-level C++ constructs to the generated assembly and CPU behavior to build an intuition for how performance improvements are realized. While the talk discusses Visual Studio code generation & optimizations, the tools and analysis apply to all native platforms & compilers.

We will also introduce sample-based profile-guided optimizations (SPGO) which uses the runtime characteristics of your application to guide optimization decisions, WITHOUT requiring traditional instrumentation. You will learn how SPGO works, how to apply it in practice, and where it delivers measurable gains: typically in the 5-15% range across real world native codebases.

Attendees will leave with a practical understanding of how to reason about native code performance, and how to leverage SPGO to turbocharge the performance of their code.

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.

AI agents are accelerating code generation at an unprecedented pace, yet C++ file is still compiled as a monolithic translation unit, meaning a many-core machine often cannot rebuild a template-heavy file much faster than a single core. Header-heavy designs, inline functions, and templates compound the problem: the same bodies are parsed repeatedly, and small edits can invalidate an entire translation unit.

This talk presents a compiler-agnostic technique for splitting translation units into smaller independently compilable units. Using libclang, the tool rewrites headers and sources into declaration-only interfaces plus generated .cpp fragments, backed by a shared preamble that can turn into a C++ module, precompiled header, cached serialized AST and a source-map. The fragments compile in parallel, then link into a binary functionally equivalent to the original monolithic build.

Expect benchmarks from major codebases covering compile-time, link-time, and run-time performance; live demos of fast incremental updates that avoid reprocessing unchanged code as well as an analysis of the resulting binaries layout.

Tooling Track sessions are sponsored by Optiver.

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.

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.

Queues are the backbone of concurrent systems — yet most C++ developers treat them as a black box. Pick the wrong queue topology, misplace an alignas, or use the wrong memory order, and you pay for it in microseconds of latency, invisible cache thrashing, or subtle correctness bugs that only manifest under load. This talk is a rigorous, bottom-up treatment of the four canonical concurrent queue topologies: SPSC, MPSC, SPMC, and MPMC. We start with the hardware reality — how cache coherence protocols turn innocent struct layout into a performance disaster through false sharing — and build upward through the C++ memory model, atomic operations, and queue algorithm design. For each topology, we derive the minimal set of memory ordering guarantees required for correctness, show how to exploit producer/consumer asymmetry to eliminate unnecessary synchronization, and demonstrate how alignas(std::hardware destructive interference size) and deliberate padding can be the difference between 100ns and 10ns throughput. We dissect Dmitry Vyukov's MPMC ring buffer, the intrusive MPSC queue, and Michael-Scott's linked-list queue — not just their interfaces, but the why behind every memory order acquire and every phantom cache line. We then go beyond correctness into the practical engineering tradeoffs: bounded vs unbounded, throughput vs latency, contention vs coordination overhead. Real benchmark data shows how these decisions interact non-obviously — an MPMC queue can outperform MPSC under certain producer counts, and seq cst where you don't need it can quietly halve your throughput. Attendees will leave with a clear mental model for choosing and implementing the right queue for their threading topology, a checklist for false sharing audits, and battle-tested code patterns suitable for low-latency production systems.

Modern C++ gives developers powerful tools to write cleaner, safer, and more expressive code — but many production codebases still suffer from excessive boilerplate, repetitive patterns, and verbose implementations inherited from older C++ styles.

This talk explores practical modern C++ techniques that significantly reduce lines of code while preserving readability, maintainability, and runtime performance.

Through real-world examples, we will refactor traditional C++ implementations using features such as ranges, structured bindings, constexpr, concepts, CTAD, lambdas, std::optional, std::variant, and std::expected. We will examine where these features genuinely improve code quality — and where they can accidentally hurt clarity or performance if misused.

The session also goes beyond syntax improvements by analyzing generated assembly, compiler optimizations, allocations, and benchmark results to validate whether “shorter” code truly remains zero-cost.

Attendees will leave with practical patterns they can immediately apply to modernize existing codebases, reduce unnecessary complexity, and write more expressive C++ without sacrificing performance.

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.