CppCon 2026

What does it take to build a real-time embedded control system in modern C++, simulate its environment, command it from a browser, and watch it fly in 3D — all from the same open source ecosystem? This talk follows that pipeline end-to-end: from a C++23 real-time framework that schedules deterministic control loops across POSIX hosts and bare-metal microcontrollers, to GPU-accelerated simulation with CUDA, to web-based operations and telemetry, to live 3D visualization in Unreal Engine.

Attendees will see how a unified runtime architecture can span embedded control, simulation, diagnostics, operations, and visualization without fragmenting into separate software stacks. The talk explores deterministic scheduling, zero-allocation real-time design, cross-platform deployment, and integrating CUDA compute kernels directly into scheduled control loops without blocking execution. It also covers tooling for validating deterministic real-time behavior, along with techniques for streaming telemetry and sensor data between simulation and visualization layers in real time.

The presentation includes live demonstrations of a quadcopter simulation flying a programmed trajectory with lidar feedback, and a full-fidelity aircraft simulation with closed-loop autopilot, engine dynamics, and atmospheric turbulence — both running through the same real-time framework and rendered live in Unreal Engine. Whether you build flight software, robotics systems, industrial controllers, or simulation infrastructure, this talk presents practical architectural patterns for modern real-time systems in C++ that bridge embedded devices, GPU compute, and interactive visualization.

Embedded systems have to operate within real limits. We care about timing, memory usage, reliability, and what happens when something fails. But storage is often treated differently. We write a file, call an API, and assume the operation will finish when it finishes. That works for a lot of systems, but it becomes harder to accept when storage is part of a real-time workload.

That led me to a fairly simple question: what would change if storage had to be predictable too?

In this talk, I'll use an embedded filesystem I built in C++20 to explore that question. We'll start with the system requirements and work our way down into the filesystem, looking at where unpredictable work can come from and what design choices can make that work easier to understand and bound.

Instead of focusing only on average execution time, we'll look at what an operation actually has to do: searching for space, accessing metadata, reading and writing blocks, handling failures, and recovering from interrupted operations. We'll also look at how those costs change as the filesystem fills up or becomes fragmented. This kind of reasoning is familiar in real-time systems—we routinely think about bounded work in schedulers, queues, synchronization, and memory management. Storage deserves the same scrutiny.

The filesystem is intentionally constrained. It uses fixed resources and bounded searches where practical, explicit ownership, and a block-device interface that keeps the filesystem separate from the underlying storage hardware. I'll also show how fault injection and instrumentation can be used to exercise failure paths and measure the work being performed instead of relying only on timing measurements.

Modern C++ is useful here, but not because using C++ automatically makes a system deterministic. It gives us tools for making some of these design decisions explicit. We'll look at std::span, std::string_view, fixed-size containers, RAII, compile-time configuration, and small abstractions that can still make sense on a resource-constrained microcontroller.

There are tradeoffs. Fixed limits give up some flexibility. Simpler allocation strategies may use storage less efficiently. Recovery requires additional work and writes. In some systems those costs are worth paying for behavior that is easier to reason about. In others, a general-purpose filesystem is the better choice. We'll look at both sides.

We'll also separate the work performed by the filesystem from the timing behavior of the storage device itself. That gives us a way to take the same filesystem design and evaluate it across different storage backends and embedded targets. Rather than asking only, “How fast did this run?”, we can start asking, “How much work did the software perform, what did the hardware contribute, and did the system behave the way we expected?”

By the end of the talk, attendees should have a practical way to think about predictable storage in embedded C++ systems and, more broadly, how to reason about resource limits, failure handling, ownership, hardware interfaces, and timing when predictability matters more than peak performance.

Building embedded systems wastes time on infrastructure instead of features. Before running application logic, developers lose hours bootstrapping init systems, wiring services, debugging startup failures, and fighting tooling never designed for constrained or early-boot environments. AEMBER is a developer-first PID1 (init system) that eliminates this overhead by providing a modern C++ runtime for process supervision, container orchestration, and service management - letting you focus on your application, not your plumbing.

This talk demonstrates how C++23 enables robust embedded systems without sacrificing performance. We'll explore std::expected for exception-free error handling, if consteval for compile-time optimization paths, and deducing this for zero-overhead policy classes. You'll see how monadic operations compose system calls into clean pipelines, and how modern C++ features build type-safe APIs for namespaces, cgroups, and process management.

Starting from main(), we'll trace AEMBER's architecture: how components compose, how errors propagate through std::expected chains, and how C++23 patterns enable embedded systems to be both safe and fast. We'll wrap up with a live demo showing AEMBER managing containers and services in real-time. You'll leave with concrete techniques for building maintainable embedded infrastructure using cutting-edge C++.

Atomic memory ordering is often taught operationally: Use acquire here, release there, and perhaps add a fence “to be safe.” This approach tends to produce cargo-cult synchronization, where atomic operations are selected mechanically without a clear understanding of what information is actually being propagated between threads. In practice, memory ordering is not about memorizing enum values, but about establishing which facts become visible to which observers, and when.

This talk approaches atomic synchronization from first principles. Beginning with the fundamental ideas of publication, visibility, ownership transfer, and synchronization edges, the talk incrementally develops several concurrent structures drawn from real asynchronous systems. Case studies include outstanding-work reference counting, a multi-producer singly-linked publication structure, a concurrently-mutated doubly-linked intrusive list, and the coordination machinery underlying a concurrent operation with multiple concurrent completion modalities. Each structure is used to derive the synchronization requirements imposed by its invariants, rather than selecting memory orderings mechanically.

Along the way, the talk explores the practical meaning of relaxed operations, acquire/release synchronization, and atomic thread fences. Particular attention is paid to understanding what each actually does, when it is necessary, and when it has become a decorative synchronization cargo cult. The goal is not simply to present lock-free algorithms, but to develop a principled way of reasoning about memory visibility and synchronization in real concurrent systems.

This session dives deep into the world of vulnerabilities from a C++ developer's perspective. Using a simple embedded device as the playground, where the memory model is stripped to the bare essentials, attendees will explore how classic attacks like buffer overflows can be used to hijack control flow, inject code, and manipulate the stack.

Everyone has heard the warnings about buffer overflows, use-after-free, memory corruption, and other infamous vulnerabilities lurking in low-level code. But many developers accept that these traps should be avoided without truly understanding how the exploits work. In this talk, attendees will see hands-on examples of how memory vulnerabilities arise, how they’re exploited, and why they’re dangerous.

But this session is not just about breaking things, it is about building them right. We will explore how modern C++ techniques like smart pointers, bounded containers, and RAII can prevent these issues altogether. By the end of the talk, developers will not only understand the risks but feel confident applying C++ best practices to write safer, more robust code.

Whether you are a systems programmer, embedded developer, or security-minded engineer, this session will deepen your understanding of C++, not just as a powerful language, but as a tool for writing secure, reliable software.

C++ is used in many fields. One that sticks out is the embedded domain. You're often working with tight constraints. Writing software is challenging and fun at the same time.

What has C++ done to support this field? What new options do you have to avoid undefined behavior and write more efficient and robust code?

In this talk, I will present various library elements as well as language improvements that make writing embedded software better.

We'll look at real-world tasks like turning raw byte blobs into usable data structures, aka type punning, of course, without triggering undefined behavior. C++23 supports you in a new way with std::start_lifetime_as .

Transferring data via a network comes with its challenges. You have to care about the byte order. Oh, and how can you make sure that there are no padding bytes included? Well, I have an answer for you.

And then there is a brand-new feature in C++26: static reflection. I will present examples of how and where reflection in C++ eases embedded development.

By the end of this talk, you know the most important improvements in C++ for embedded or similar environments.

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.