CppCon 2026

The White House says stop using C++. CISA wants a memory safety roadmap. The internet says rewrite everything in Rust. Meanwhile, embedded teams are shipping firmware on Cortex-M microcontrollers with limited flash, no MMU, no virtual memory, and a codebase that cannot be rewritten overnight. So what do you actually do?

This talk is a practical, tool-by-tool walkthrough of every memory safety technique available to embedded C++ developers right now — and what is coming in C++26. It starts with what you can turn on today without changing a single line of code: compiler warnings that most projects still ignore, AddressSanitizer and UndefinedBehaviorSanitizer running on host-compiled firmware, and stack protection options that cost single-digit bytes of overhead. It then moves to code-level improvements that modern C++ makes possible: replacing raw pointer arithmetic with std::span, using std::expected instead of error codes that nobody checks, applying constexpr to move validation to compile time, and adopting strongly typed wrappers to eliminate unit-of-measure bugs. Finally, it covers what C++26 brings to the table — hardened standard library containers with bounds checking at 0.3% overhead, safety profiles for type and bounds and lifetime checking, contracts for defensive preconditions, and the elimination of uninitialized-variable undefined behavior — and evaluates which of these features are realistic for embedded targets today.

Every technique is evaluated on three axes: how much code do you have to change, what does it cost in code size and runtime on a real microcontroller, and what class of bugs does it actually prevent. Attendees will leave with a prioritized adoption checklist they can bring back to their team on Monday.

An overview of contemporary hardware platforms and how software engineering and design practices and methodologies could help in building performant systems, with a particular focus on low level optimizations. Contrary to attempting direct low level software engineering for addressing performance specifics, this talk would focus on how higher level abstractions could and should be used, and how a software engineer could help the compiler to “do the right thing”. The trend of moving software engineering focus upward to constructs that have a tendency of hiding the specific of the underlying platform is quite clear – and there certainly are very good reasons for such a paradigm change.

Performance matters. Premature optimization is evil. Is there anything in between those two extremes? How feasible is it to rely on the abstraction of the platform as hidden by the compiler and the corresponding libraries and language constructs, expecting that it will be able to realize the intended lower level optimizations? How much of hints and specifics would one need to expose for the compiler to be able to get the equivalent of direct low level approach? What is the right balance between expressing application logic via higher level construct yet still being able to gain the performance benefits compared relying on the low level specifics?

Looking from the practical applicability of lambdas, iterators, ranges, coroutines, error handling, and safe(r) memory access, the talk would attempt to cover a set of use cases with a focus on analysis of what could be done for focusing on performance.

The overall goal of the talk is not to go deep into low level aspects; the goal is to explain that one needs to be aware of such low level details while operating on the higher level constructs.

The software in most embedded projects written in 2026 looks like the software in embedded projects written in 1996. This isn't because 1996 was the peak of innovation and quality but rather has more to do with biases and FUD. Unfortunately, much of the world suffers from these choices: users, developers, managers, and shareholders.

There are better ways to write firmware for embedded systems; proven techniques and implementation strategies that I will describe in this talk. We will explore techniques based on abstraction and composition that maximize understanding while reducing the codegen footprint. We will apply these strategies at all levels of the firmware stack: interrupts, register manipulation, peripheral communications, and the application glue.

Join me and leave with open-source libraries, an open-source starter project, and techniques that you can apply to your greenfield and existing projects.

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.