CppCon 2026

The architecture of legacy compilers presents limitations for modern software development. As codebases scale, developers face increased compilation times. While language complexity is often cited, key architectural bottlenecks include pointer-chasing across deeply nested ASTs (cache misses), single-threaded type resolution, and significant thread-lock contention (RwLock) during parallel semantic analysis. What happens when we discard the Abstract Syntax Tree entirely and apply strict Data-Oriented Design to the compiler itself?

In this session, we will explore the internal architecture of the Vx compiler frontend—a heterogeneous systems programming language to safely maximize utilization of available CPU cores. We will dissect how to translate complex, tree-like program semantics into flat, contiguous arrays of 256-bit bit-packed Global Identifiers (GIDs).

By stepping away from traditional recursive tree-walking and object-oriented compiler design, attendees will learn how to implement high-throughput parallel pipelines.

This talk is not just for language designers. The architectural patterns used to build the Vx compiler—flattening graphs into arrays, deferred identity, and lock-free synchronization boundaries—are directly applicable to any C++ developer building high-performance, multithreaded systems.

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.

C++ runs the world’s systems, and with that comes a responsibility for safety and stability. Avoiding AI entirely gives up on incredible potential benefits, but using AI without guardrails poses significant risks to our critical systems. How does AI fit into this world? This talk examines effective and ineffective approaches to using AI in systems that cannot afford “slop.” We will explore several case studies where AI produced significant value in C++, and several where it did not. The pattern that emerges is consistent: AI thrives when it is orchestrating well-defined, deterministic components, translating between them intelligently without being trusted to reason correctly on its own. When AI is asked to be the system rather than connect the system, things fall apart.

As of C++11 there are 6 special member functions that the compiler will generate for us if we don't do anything to get in the way.

But there are many other member functions, in the form of comparison operators, that we can =default explicitly

Which of these should we =default? How do we help the compiler, or stay out of its way?

How many do we need to implement? When can you trust the compiler or not?A

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.

Refactoring is defined as "the process of changing a software system in a way that does not alter the external behavior of the code yet improves its internal structure", and is a core skill and process in modern software development. From "cleaning up a little mess" to handling legacy code to improving testability to completely changing architecture, refactoring is the process to achieve that elusive thing, "clean, elegant, and maintainable code".

This talk will cover the basics of Refactoring from three angles. First, we will cover a few of the most important refactoring techniques and connect them to other well-known points of good C++ style.

Second, we'll talk about how to decide what and where to refactor. Common "code smells" are good places to start, but we will also discuss how to look for "seams" along which code can be cut, and how to find hints left in the code by previous developers that can point the way.

Third, we'll discuss how to successfully execute refactoring, even on a busy team and a big code base. What is the "blast radius" of a change, how to minimize the disruption it causes, and how to avoid annoying co-workers in the process.

Have you ever wondered why your C++ class suddenly doubled in size, or why reordering its members made it smaller? This talk introduces memory alignment in C++ from the ground up - what it is, why it is critical, and how compilers handle it under the hood. We’ll start from first principles: how modern CPUs read memory, the difference between aligned and unaligned access, and the performance costs of getting it wrong. Using benchmarks, we’ll see just how impactful misalignment can be. From there, we’ll dive into how compilers lay out data members in structs and classes, and how simple reordering can reduce memory footprint. Live coding examples will illustrate how padding is introduced and how tools like alignas, alignof, and std::align give you precise control. We’ll also look at packed data structures, which trade alignment guarantees for compactness - common in network protocols. While they can save space, they also introduce risks like undefined behavior when misused. Through real-world examples, you'll learn when packed structures make sense, and when they’re a hazard. By the end of the talk, you'll walk away with a solid intuition for alignment and the confidence to manage memory layout effectively in your programs.

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.

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<expected<T, E>> separates async completion from domain failure into orthogonal axes: errors short-circuit through monadic composition (and_then/or_else), and each step has a pure-functional signature that developers on the team can read, test, and extend. The combination‚ coroutines for structure, expected for error flow‚ is what makes the workflow genuinely readable.

Attendees will leave with: (1) the two-axis decomposition (async completion vs. domain outcome) and why separating them changes how you design every step, (2) a four-question framework for evaluating any async architecture, and (3) concrete patterns for partial-failure handling in coroutine fan-out.

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.

Last year I introduced the SDL3 library which provides a solution for building games and graphical applications on multiple platforms. In this talk, we will continue our journey into SDL3, which newly includes the ability to write shaders within the built-in 2D API. My goal is to get you up and running fast by building out a small game application. Throughout the talk I will show how to build a small 2D framework, discussing design decisions and which C++ features can be used to help organize our code. Attendees will leave this talk ready to build multimedia / game applications and with an understanding on if SDL3 is the right tool for them.

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.

Every C++ developer runs their build system dozens of times a day, yet few think about what it actually computes. Underneath every cmake --build or ninja invocation lies a directed acyclic graph, a DAG of dependencies that determines what gets rebuilt, in what order, and how much parallelism is available. When builds are slow, when incremental rebuilds trigger more work than expected, or when CI bottlenecks in surprising places, the root cause is almost always a structural property of this graph. Most developers never look at it.

This talk makes the build graph visible and actionable. Through curated examples, we will visualize dependency graphs and expose the common pathologies: overly connected "hub" headers that invalidate half the build when touched, deep critical paths that starve parallelism even on a 128-core machine, and accidental edges introduced by includes that no one questioned. These are not just build performance issues: they are architectural issues wearing a different hat. Your build graph is the ground truth of your codebase's structure, whether or not it matches the diagram in your team's documentation.

Armed with this mental model, we will walk through practical techniques for reshaping the graph: measuring critical path length from .ninja_log , identifying high-fan-in nodes, breaking costly edges with forward declarations and interface segregation, and using graph analysis as an automated architectural fitness function in CI. Worked examples will show concrete before-and-after measurements. You will leave with a new way of seeing your codebase, not as files in folders, but as a graph you can visualize, measure, and deliberately reshape.

Tooling Track sessions are sponsored by Optiver.