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.

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.

How far can C++26 reflection take us? What are some techniques, gotchas, limitations and workarounds? How would reflection help write code that interacts with bespoke binary data formats? Come along as we explore a practical example together.

This talk will review advice gleaned from applying C++26 reflection to binary (structs on a wire) protocol handling. This type of protocol exists all around the world from financial market data formats to custom hardware interaction. Is the proposed reflection support enough to take a protocol definition written in the native terms of C++ and create flexible components to interact with that protocol?

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.

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.

Every software engineer needs to understand the fundamentals of how your computer works. My mantra for teaching computer systems is 'no more magic', and in this talk I'll do my best to dispel what feels like 'magic' in our hardware in a single hour. In this talk, we will investigate '3' pictures of the 'the compilation process', 'program stack', and a 'cpu' to understand how these components work together to ultimately compile and execute code. An emphasis during this talk will focus on the 'CPU' and the hardware components (e.g. registers, cache memory, main memory, page table) interact with the operating system to efficiently execute a program. Hardware will be presented side-by-side with code so we can understand what happens in the hardware as software executes. Attendees will leave this talk with a better mental model of how their hardware works, and the implications their software design choices have on performance.

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

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.

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.