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 on the recent work of improving the quality of Sea of Thieves' codebase by upgrading from C++14 to C++20, this talk will focus on the work that has went into enabling warnings as errors on the game, and more.

Rare will discuss the motivations behind wanting to crank up the warning level, and to flick the "warnings as errors" switch after 10 years of development in their multi-million line Unreal Engine code base.

What were the challenges? How much effort did it take? Was it worth it? Did we find any bugs? Did we stop at just "/W4 /WX"? What warnings did we find the most useful? What warnings were deemed unhelpful? All of these questions and probably more will be answered throughout this session.

Modern C++ development has embraced package managers like Conan and vcpkg for dependency management, gaining reproducibility and productivity. However, a significant weak point remains: the build toolchain. Unlike standard dependencies, the disparate set of tools comprising the compiler, linker, standard libraries, and OS-specific headers often remains outside this managed ecosystem. This gap leads to frequent complications, where misaligned versions between local environments and CI cause build errors and subtle ABI incompatibilities.

The operational cost of maintaining these toolchains is high. Updating a compiler version often necessitates the creation and deployment of new VM images or manual infrastructure updates, a process that can be even more complex if specialized environments like CUDA are involved. These hurdles directly impact engineering productivity and organizational alignment. Docker is a popular solution to isolate toolchains, but it does not support all the mainstream platforms.

This talk proposes a shift in perspective: treating the build toolchain as just another dependency. We will explore how leveraging toolchain isolation allows developers to express specific toolchain versions within their project manifests—using cross-platform tools like Conan and vcpkg to ensure strict repeatability across local developer environments and CI machines.By automating the fetching and configuration of the entire compiler suite, teams can ensure perfect alignment across all environments, simplify the upgrade path, and ultimately boost engineering velocity.

Tooling Track sessions are sponsored by Optiver.