CppCon 2026

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.

Getting a project approved, or killed, often has less to do with technical merit than with who actually holds the keys and what they need to hear. This talk draws on real case studies from library design fights, cross-functional infrastructure rewrites, and a couple of notable failures to show practical techniques: how to find the real decision-maker, how to break expert deadlock with a position paper, and how to build toward an audacious goal through incremental wins and a well timed crisis.

For C++ developers building modular applications or performance-critical loops, modern architecture often forces a painful compromise: you either build heavily decoupled systems that thrash the CPU cache, or you write rigid, tightly coupled code. Distributed builds mask the compile-time symptom — but the underlying coupling bleeds into the runtime hot path.

This talk presents the Capability Routing Grid (CRG), an architecture that refuses this compromise. CRG enables a zero-registry plugin system where modules self-register at link time, and polymorphic dispatch is reduced to an O(1) branchless array lookup — with no central registry, no Init() function, and no runtime search.

Three independent pillars, each usable standalone:

Pillar 1 — Linker-Driven Discovery: Build a fully decoupled plugin system without central registries or Init() boilerplate. Modules self-register via standard C++ static initialization — entirely automatic in monolithic builds, and requiring a single explicit sync-point call at DLL load time.

Pillar 2 — State and Behavior Separation: Enforce a strict architectural boundary between pure data structs and stateless capability objects. This separation — not a framework — is what keeps the hot path flat. Type erasure is available as an optional cold-path utility for cross-boundary routing, but is never required for performance.

Pillar 3 — O(1) Branchless Dispatch: Map multi-dimensional contextual states into a single flat lookup table using basic polynomial math. Because this layout never changes, the CPU branch predictor and hardware prefetcher maintain peak efficiency.

The final payoff: by collapsing capabilities into raw function pointers, the system hits the memory bandwidth ceiling — 33 GiB/s sustained throughput, with a per-dispatch tax of approximately 1.5 nanoseconds.

Data-Oriented Design is defined from scratch. A brief hardware cache primer precedes every performance claim. The entire architecture compiles on C++17 — no language extensions, no experimental flags, on any mainstream toolchain. The audience will leave thinking, "I could have written this" — because they can.

Attendees will learn how to: - Build self-registering plugins with zero shared headers, using standard static initialization across both monolithic and DLL builds - Apply state/behavior separation as an architectural discipline — keeping capabilities stateless and the hot path free of virtual overhead - Replace vtable dispatch with a flat array lookup across N behavioral dimensions — O(1) regardless of dimensionality - Cache resolved logic as raw function pointers and call them directly, reaching memory-bound throughput

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

Large-scale robotics organizations operate diverse fleets of manipulators — 4-DOF arms on rails, 6-DOF standard manipulators on pedestals and fully mobile manipulators — each with different kinematics, hardware vendors, and software teams and researchers.

And engineers and researchers are opinionated.

As a team eventually you have one goal. Re-use as many abstractions; ideas and algorithms as you can while still allowing you the flexibility to explore new algorithms; ideas and approaches.

This talk presents a layered C++ architecture that solves this at scale. We present our core abstrcactions; a header-only Lie group library provides shared spatial math types (SE(3) poses, twists, wrenches); a trajectory library for motion planners and controllers; and a collision detection library from the same.

We will discuss how we moved from virtual functions to C++ concepts with zero overhead and the learnings along the way that allow us to write planning and control algorithms for various robots morphologies and sensing paradigms.

Critically, this architecture balances the needs of production at scale while enabling experimentation: researchers can prototype new collision algorithms, try a new physics engine, or test a novel trajectory representation — all without disrupting production code. The backend boundaries are where new ideas enter the system. You'll leave with three distinct C++ patterns for backend abstraction — compile-time traits, runtime interfaces, and type erasure — and an understanding of when to use each based on performance requirements and the need for experimentation.

A fundamental control structure of each programming language are loops. And we all expect them to be simple and self explanatory. However, C++ would not be C++, if there would be no tricky details to learn and respect about loops in C++.

This talk takes its time to discuss the various ways and approaches to program loops in C++. Beside basic while and for loops, we talk about the range-based for loop, and all the extensions recently added to these control structures.

In addition, we will look at other ways to program loops in C++, such as using algorithms and how to deal with parallel computing in a loop.

As a result you get a deeper understanding of the various ways loops can be programmed in Modern C++ so that you know better how to use them in practice.

Your system supports multiple strategies, with the user selecting one at startup, but each strategy must handle different semantics. Traditional runtime polymorphism can require a virtual override for every combination, making code harder to extend and easier to get wrong

This talk shows how OpenJDK solves this problem by using a layered architecture of compile-time patterns with a runtime trampoline. We'll build them up through OpenJDK's GC barrier system, where a single templated API stands in for dozens of differently-shaped memory accesses across the runtime: plain stores, raw/unsafe access, native calls, weak references, and more, each needing different treatment depending on the semantics and which garbage collector was chosen by the user.

We'll also discuss trade-offs against std::variant, function pointers, and plain virtual dispatch. No JVM knowledge required.

Application developers sometimes hit a limitation of a 3rd-party library or framework. The Type Erasure design pattern can help us overcome such limitations without the need to change the 3rd-party API.

Type Erasure is a relatively complex design pattern that allows us to treat a set of unrelated classes as if they shared a common base class, while preserving value semantics. The downside is increased code bloat and code complexity as the pattern requires a significant amount of additional code.

There have been quite a few talks explaining HOW to implement Type Erasure, while the topic of WHEN has been rarely discussed. Should we always use type erasure instead of virtual polymorphism? And if not, then what are the criteria?

This talk will show a concrete example from the audio programming industry of how Type Erasure allowed adding new functionalities to the parameter class system of the JUCE C++ framework without changing its API. As such, the talk will be useful for application and library developers who use 3rd party libraries but need an extra degree of flexibility.

You will come out of the talk understanding

• what Type Erasure is,
• when to use it, and
• how to implement it.

You don't need to understand Type Erasure, audio development, or JUCE to attend the talk; the necessary minimum will be explained during the talk.

AI agents are accelerating code generation at an unprecedented pace, yet C++ file is still compiled as a monolithic translation unit, meaning a many-core machine often cannot rebuild a template-heavy file much faster than a single core. Header-heavy designs, inline functions, and templates compound the problem: the same bodies are parsed repeatedly, and small edits can invalidate an entire translation unit.

This talk presents a compiler-agnostic technique for splitting translation units into smaller independently compilable units. Using libclang, the tool rewrites headers and sources into declaration-only interfaces plus generated .cpp fragments, backed by a shared preamble that can turn into a C++ module, precompiled header, cached serialized AST and a source-map. The fragments compile in parallel, then link into a binary functionally equivalent to the original monolithic build.

Expect benchmarks from major codebases covering compile-time, link-time, and run-time performance; live demos of fast incremental updates that avoid reprocessing unchanged code as well as an analysis of the resulting binaries layout.

Tooling Track sessions are sponsored by Optiver.

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

Last year I introduced the SDL3 library which provides a solution for building games and graphical applications on multiple platforms. In this talk, we will continue our journey into SDL3, which newly includes the ability to write shaders within the built-in 2D API. My goal is to get you up and running fast by building out a small game application. Throughout the talk I will show how to build a small 2D framework, discussing design decisions and which C++ features can be used to help organize our code. Attendees will leave this talk ready to build multimedia / game applications and with an understanding on if SDL3 is the right tool for them.

Python's Global Interpreter Lock, which determines which single thread can execute native Python code and call C API functions, simplifies writing multithreaded code. By default, the most popular C++ bindings to this API, pybind11 and Cython, implicitly enables the GIL by default. However, sticking with this execution model leaves out extra performance afforded by modern multicore CPUs with hyperthreading, as automatic locking and unlocking of the GIL does not scale well with thread counts, especially in performance-sensitive workloads.

The newfangled free-threaded interpreter promises salvation when running either pure Python code or with compiled extensions. General multithreading rules apply (prefer thread-local variables, using locks to prevent simultaneous access of shared data), but when dealing with projects containing compiled extensions that directly or indirectly interface with Python's C API, more porting rules also apply.

Key porting tips, including projects using the Limited API, include: port native code away from C API functions that avoid borrowed references because they aren't thread-safe; modify unit tests to catch concurrency bugs arising from assuming the presence of the GIL; and extend CI coverage of Python interpreters both for testing and to build free-threaded compatible wheels.

Tooling Track sessions are sponsored by Optiver.

In CPython 3.14, we introduced an alternative interpreter implementation. This implementation used [[musttail]] , an experimental C/C++ feature that tells the compiler to enforce tail calls. Against the previous interpreter using computed gotos/switch-case, the new interpreter style shows 2%--15% performance improvement (i.e. geometric mean running time), and is more resilient against certain types of compiler bugs. This feature is already supported by Clang, GCC, and MSVC, and is also the center of a draft proposal targeting C++29. In this talk, I’ll cover the story of getting this feature into the Python interpreter, our collaboration with compiler developers, and the potential wider impact on the C++ community. I’ll also cover interesting use cases of this feature other than for writing interpreters, such as for automatically generating a simple Just in Time (JIT) compiler.

Tooling Track sessions are sponsored by Optiver.

Production C++ code often hides small but deeply complex algorithms inside layers of engineering: APIs, lifetimes, error handling, integration, logging, and glue code. We test classes and systems, but rarely the algorithm itself in isolation.

Off-by-one errors and broken or missing invariants can survive extensive pre-production testing. Line coverage does not imply branch coverage. Branch coverage does not imply coverage of algorithmic corner cases. Testing through a wide public API often obscures the mathematical structure of the problem, making subtle bugs difficult to discover through multiple layers of abstraction.

This talk explores how to extract an "algorithmic core" from a larger component. Its correctness is fundamentally mathematical and largely language-agnostic rather than C++-specific.

Using examples such as substring matching, topological sorting variations, and lazy evaluation on trees, we will examine how problem corner cases differ from implementation corner cases, and how easily some of them are skipped.

We will discuss:

• Recognizing when an algorithm is entangled with boilerplate
• Extracting core logic without introducing accidental complexity
• What it takes to test algorithmic code in isolation
• Raising the level of abstraction to make reasoning easier without merely relocating complexity
• Using LLMs to assist in exploring and validating implementations
• Gradual rollout and comparison of competing implementations

Notifiers are a critical synchronization primitive in task-parallel programming systems such as Intel TBB and Taskflow, responsible for efficiently sleeping and waking worker threads as tasks become unavailable and available over and over again, directly impacting scheduler throughput and latency. Correctness here is non-negotiable: a single missed wakeup can significantly hamper the performance of an entire program. Yet writing strong unit tests for notifiers is notoriously difficult, because the bugs they target, lost wakeups, spurious wakes, race conditions, are timing-dependent, non-deterministic, and often only surface under specific thread interleavings that are hard to force reliably.

The problem is compounded in practice. Notifier implementations evolve constantly: small algorithmic tweaks, memory ordering changes, and refactors across systems demand a fresh round of carefully constructed tests. This is tedious, expertise-heavy work that takes a lot of time and engineering effort. In this talk, we explore using Large Language Models (LLMs) to automate the generation of the unit tests for notifiers. Specifically, we will demonstrate how LLM-generated tests, guided by proper prompts can systematically stress the two-phase wait protocol across Notifiers in Taskflow. We will show this in a widely used Notifier implemented in Taskflow. We are able to find an undiscovered bug that has been existing in the project.

Benchmarks shouldn't live in a different world from tests. Most C++ projects already use Google Test, but the moment performance enters the picture, developers reach for separate tools, separate workflows, and ad-hoc timing loops that don't survive contact with CI. This talk argues for a different default: treat performance measurements as first-class tests. They are written in the same harness, run in the same suite, and fail the same builds.

Using a real C++23 framework built on top of Google Test, the session shows what that looks like in practice. Semantic macros distinguish throughput, latency, and contention tests; built-in statistical analysis tracks medians, percentiles, and coefficient of variation. Adaptive thresholds scale with payload size, so tiny operations and multi-megabyte workloads aren't held to the same stability expectations.

Once benchmarking lives inside the test framework, the rest of the performance toolchain follows. Five CPU profiler backends drop in behind a single --profile flag: perf, gperftools, bpftrace, RAPL, and callgrind. Attaching a memory profile to a test prints bandwidth, efficiency, and a CPU-bound or memory-bound classification with no extra code. The same harness extends to CUDA through a fluent kernel builder that captures launch configuration, achieved occupancy, transfer overhead, multi-GPU scaling efficiency, and thermal throttling. Nsight Compute drops in through the same --profile flag.

The payoff is CI integration that's nearly automatic. A companion CLI tool compares baseline and candidate runs, applies statistical thresholds, posts markdown reports on pull requests, and fails the build on regressions. The result is a single workflow for performance verification that scales from a developer's laptop to a CI runner to a Jetson on a workbench, across hardware ranging from x86 to ARM to RISC-V.

Tooling Track sessions are sponsored by Optiver.

Years ago while working on a service that would be deployed in Kubernetes, we decided to use the simplest possible TCP based healthcheck. Not because TCP was the right choice, but because implementing a simple HTTP endpoint was more code than it was worth. For our Go services the equivalent HTTP endpoint was only a couple of lines. In fact, we eventually ended up replacing our TCP endpoint with a small Go wrapper around our C++ service.

The Go standard library has done a great job at designing a very ergonomic HTTP library. C++ now has all the right building blocks to express the same design concepts: coroutines, concepts, std::expected, std::jthread. The question is, do these patterns transfer from Go to C++? How do we evaluate the effectiveness of the resulting design?

In this talk I will present a small HTTP library inspired by Go's net/http, built with the tools available in C++23. To evaluate the resulting design I will draw on ideas from Felienne Hermans' The Programmer's Brain and the principle, from Structure and Interpretation of Computer Programs, that API design is language design.

Along the way we'll see which patterns transfer cleanly, which need translation, and why telling the difference is a skill worth developing even if you only work with C++.

Most C++ programmers are familiar with the traditional C++ facilities for text processing found in the iostream and string libraries. However, std::format (C++20) and std::print (C++23) provide new text formatting tools that are unfamiliar to many C++ programmers. While these new facilities can be very helpful, they can also produce some very intimidating error messages when misused. Moreover, the process for writing your own user-defined types that you can format with std::format and std::print is not very straightforward.

This session starts with an overview of the traditional C and C++ text processing libraries. It then shows how std::format and std::print neatly combine benefits from both the C and C++ libraries to create a safer, more convenient interface. After that, this session explains the steps you must take to write user-defined types that work cleanly with std::format and std::print. You’ll leave this session with a clearer understanding of the benefits of using these new text formatting facilities and how to integrate them into your existing code base.

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.

Air-gapped systems used to be protected by what they could not reach. That assumption breaks when telemetry, sensor data, and diagnostic output leave the system and AI model-influenced behavior comes back in, even without a network connection.

This talk examines the C++ engineering decisions that determine whether that data exchange is safe or silently dangerous. The problems are C++-specific and subtle: struct layout and padding that corrupt data silently across serialization boundaries; undefined behavior in type-punned casts that passes tests but breaks under a different compiler or optimization level; ownership and lifetime assumptions that hold inside the system but become dangling references once data crosses a trust boundary; allocator and exception constraints in no-exception embedded environments that make standard validation patterns unavailable.

We will look at how C++ systems in industrial, embedded, and safety-critical environments can export logs, telemetry, and traces into AI pipelines without creating feedback loops that affect production behavior in unverified ways. The engineering controls are concrete: typed serialization boundaries that make layout assumptions explicit, schema validation that survives ABI differences between host and edge, provenance tracking built into ownership types, deterministic guardrails around probabilistic inference outputs, and fail-safe fallbacks that don't rely on the model being correct.

Attendees will leave with a design approach for integrating AI-adjacent workflows into high-integrity C++ systems. One that treats the data boundary as a first-class security surface, not an afterthought.

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.