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.

Floating point has a reputation for betrayal. Change the thread count, vector width, compiler flags, reduction tree, or target architecture, and the low bits can move. Parallel algorithms make this worse: the standard often specifies the operation, but not the numerical expression whose result must be reproduced. This talk asks a provocative question: what if reproducible numerics did not have to be slow?

We will show reproducible, deterministic implementations of reduce and scan that exhibit better error behavior on hostile floating-point workloads and can match or beat conventional standard-library implementations on realistic workloads. The trick is not to freeze the execution schedule. It is to specify the expression being computed, then let the implementation use SIMD, threading, blocking, tiling, and platform-specific strategies to compute that expression efficiently.

The key idea, developed through C++ standardization work such as P4016R0 and P4229R0, is reproducibility by reproducing the computation. Instead of asking the implementation to promise a particular schedule, we give the calculation a named expression. Once that expression is chosen, changing the thread count, vector width, chunking, or blocking strategy does not silently change the answer.

A reproducible scan makes this harder than reduce because it does not expose only one final value. It exposes every prefix. A reproducible final sum is not enough if the intermediate results still drift. We will show how expression and observation contracts make those prefixes reproducible without forcing the computation back into a slow sequential order.

Then we go below the algorithm layer, to the places where bits usually escape: FMA contraction, denormals, floating-point environment choices, math-library approximations, and vectorized transcendental functions. The goal is not to get the same answer by turning off the hardware. We will show reproducible vectorized primitives, including transcendental functions, running at speeds comparable to established vector math libraries while preserving a cross-platform numerical contract.

Finally, we put the whole stack under stress: a heterogeneous numerical pipeline across x86-64, Apple Silicon, and CUDA. The data is deliberately hostile, with high cancellation rates and fragile intermediate states. The aim is not to pass friendly benchmark cases, but to reproduce the specified computation, including the same intermediate failures, not just the same final answer, bit for bit, across CPUs, GPUs, and toolchains.

In the C++ ecosystem, we have powerful tools for understanding our programs before, during, and after they run. But compiler warnings, clang-tidy, cppcheck, sanitizers, debuggers, profilers, and coverage tools all answer different questions, and using them well starts with knowing which question you are asking.

This talk introduces code analysis from first principles. We will compare static techniques such as compiler diagnostics, linting, and include analysis with runtime techniques such as sanitizers, coverage instrumentation, and profiling. We will also briefly connect these tools to the direction of modern C++, including C++26 contracts and standard library hardening, where some assumptions that used to live only in comments, documentation, or debug modes become part of the program's checkable structure. Through small C++ examples, we will see what each category of tool can reveal, what it cannot prove, and how the tools complement each other.

Attendees will leave with a practical mental model for choosing the right analysis tool for the task at hand, interpreting its output, introducing analysis into an existing C++ codebase, and writing code that is easier for both humans and tools to understand.

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.

Memory leaks are very hard to treat. We have reliable tools like valgrind or AddressSanitizer to tell us whether or not an application has leaked memory, but current tools cannot tell us where the leak happens (they can tell us where the allocation happened,which is not the same).

I show that it is possible to run an analysis that is equivalent to running a garbage detection pass after every instruction and use that to find the actual cause of memory leaks in open source applications.

Using a garbage detection algorithm on record-and-replay recording, one can overcome the most obvious obstacle: stopping a program a program after every instruction or running garbage detection algorithms is very slow, but we can effectively run a bisection search on the recorded timeline to avoid having to evaluate after every instruction.

The goal is attribution to source code. Are we limited to reporting the instruction that overwrites the last reference to allocated memory or can we actually diagnose a specific error for a concrete function?

Was generating lines of code / upping the commit count the major impediment to delivering stable production ready software?

AI-assisted development has lowered the barrier to churn out code, helped engineers move faster in unfamiliar codebases, and made legacy systems easier to approach. however increased code output does not automatically mean better delivery of more reliable code.

In this talk, we will look at some of the emerging problems that are now becoming evident with AI ***amplifying existing weaknesses** such as code duplication, larger pull requests and the temptation to accept plausible generated changes without sufficient scrutiny . AI does not remove the need for engineering judgment. It removes the friction that used to slow down code creation

We will explore practical lines of defense to effectively reinforce long-term codebase health including stronger pull request descriptions, shared reviewer responsibility, review checklists, and metrics

The goal is not to reject AI. The goal is to ensure that AI improves engineering delivery rather than accelerating technical debt.

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++.