CppCon 2026

Embedded systems often operate under strict timing and reliability constraints, yet most existing file systems prioritize throughput and flexibility over predictability. This mismatch can lead to non-deterministic behavior, unbounded latency, and difficult-to-debug failures in resource-constrained environments. In resource-constrained environments such as automotive control units and aerospace flight systems.

This talk explores the design and implementation of a deterministic file system built specifically for embedded systems using modern C++. Rather than focusing on feature completeness, the system prioritizes predictable behavior through fixed block allocation, metadata-first layouts, and bounded operation times.

We will examine how determinism can be treated as a first-class design constraint, influencing everything from on-disk structure to API design. The talk will also highlight how modern C++ features—such as strong typing, RAII, and compile-time configuration—can be leveraged to enforce correctness and reduce runtime overhead without sacrificing clarity.

Attendees will gain insight into real-world tradeoffs required to achieve determinism, including limitations in flexibility and storage efficiency, as well as strategies for adapting the design across different hardware backends such as file-backed devices, SPI flash, and embedded Linux block devices.

This session is aimed at engineers building systems where predictability matters more than peak performance, and who want to apply modern C++ techniques to low-level, resource-constrained environments.

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.

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.

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.

Range views enable a “no raw loops” style of programming — not as a matter of taste, but as a pragmatic way to reuse well-tested algorithms to write code faster, express intent clearly, and avoid common bugs. In practice, however, developers often run into issues that may lead them to abandon ranges altogether:

• unintuitive behavior and surprising limitations
• slower compilation and runtime performance compared to raw loops
• high complexity when implementing custom views

In this talk, we’ll distill the core design choices behind these problems — and the alternatives that avoid them. In particular, we’ll compare:

• iterators and indices
• external and internal iteration
• transformations of nested views that overcome limitations of internal iteration

Attendees will leave with practical insights for designing and using range abstractions, along with examples of libraries that embody these ideas.

How far can modern C++ push an emulator before performance stops being a C++ problem and becomes a systems problem? This talk is the final part of a CppCon trilogy about building an extremely fast Game Boy emulator in modern C++, moving from high-performance emulation techniques to the limits imposed by hardware, compilers, and CPU architecture.

The target is intentionally absurd but not arbitrary: a Game Boy emulator running Tetris at roughly 100 times original speed, about 6,000 frames per second. However, the goal is not to support every Game Boy cartridge ever made. This project deliberately specializes for one iconic game first, using the code paths Tetris actually exercises as a guide, while keeping enough design discipline to test other games later. That means questioning the architecture of the emulator itself: instruction dispatch, memory access, generated code size, cache behavior, branch prediction, compile-time computation, benchmarking methodology, and the tension between accuracy, maintainability, flexibility, and raw throughput.

This is not a victory-lap performance talk. It is a measurement-driven engineering investigation. Rather than treating 6,000 FPS as just a headline number, this talk treats it as a stress test: a way to force difficult design decisions into the open. Attendees will leave with concrete lessons about performance-oriented C++: how to measure methodically, how to specialize without losing control, how to reason about modern CPU behavior, and how to decide when an optimization is worth its cost.

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.

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.

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.

Scripting in a C++ game engine should not cost you the engine's native performance. This talk shows how C++26 static reflection and std::meta::substitute in particular can lift a scripting language's bytecode into C++ template structures that the compiler optimizes away entirely, collapsing the interpreter dispatch loop into the same machine code you'd write by hand. Scripting languages like AngelScript and Lua are invaluable in C++ engines: they give designers a fast iteration loop without rebuilding the engine. But they come with a paradox. The engine you chose for raw performance now spends cycles on every frame interpreting a slower language, juggling a software stack and checking types at runtime. We will walk through the technique step by step, starting from a plain bytecode interpreter and ending at a fully reflected program where a scripted sum(0..10) compiles to mov eax, 45; ret. Along the way you'll learn the core C++26 reflection primitives (^^, [: :], std::meta::substitute), how to assemble bytecode into structural templates like block<> and loop<>, and how these techniques generalize to embedding any stack or register based scripting language in your engine with zero runtime overhead.

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.