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.

Some of the most expensive C++ bugs are not caused by obscure language features. Instead, they emerge from code that looks reasonable: shared ownership that quietly extends lifetimes, singletons that become invisible dependencies, and performance-driven decisions that harden into architecture.

This talk examines these common design-level failure patterns in large-scale C++ systems. We cover three concrete design shifts:

Lifetimes: Shifting from shared ownership to explicit lifetime boundaries. Coupling: Shifting from implicit global coupling to injected dependencies. Interfaces: Replacing permissive APIs with constrained interfaces using std::span, std::optional, std::variant, and strong types.

Each shift is presented with the failure pattern it addresses, the solution, and the design rule it yields. Attendees will leave with practical heuristics for designing systems that are easier to reason about, test, and evolve: all grounded in real-world failures and the redesigns that fixed them.

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?

Tooling Track sessions are sponsored by Optiver.

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

For almost 30 years, Visual Studio has been a core part of the C++ developer's toolkit on Windows. This year, we're building on that foundation with investments across three themes: making the IDE faster and more responsive for large codebases, advancing compiler conformance and runtime performance, and integrating AI-powered workflows that help you debug, refactor, and optimize more effectively. Beyond the IDE, we'll show you how AI-powered command-line tools can become a natural part of your development process. This session combines demos and practical guidance so you can get the most out of these tools right away. Come with curiosity, leave with new techniques you can apply immediately.

You found the perfect C++ library. But you cannot integrate it with your CMake build without reading three pages of bespoke instructions. The documentation (if any) is a Doxygen-generated API dump. You file a bug, get "read the source," and move on. You never adopted it—and you had every intention of doing so.

Or you are the author of that library. Technically brilliant. Six months after release: three users, no contributors, two support tickets, you are not sure how to answer. Drawing on years of experience as both a maintainer of mp-units — a high-visibility, standards-track C++ library — and as a developer who regularly evaluates and contributes to third-party C++ projects, I have watched this pattern repeat across dozens of technically excellent libraries. The barriers that drive users away, frustrate potential contributors, and quietly kill great projects are predictable. More importantly, they are fixable.

This talk traces the five stages every C++ library must survive — Discovery, Evaluation, Integration, Contribution, and Community — and examines the concrete engineering decisions at each. We will look at how naming, README structure, and CI signals communicate trust to a user who found you three seconds ago; how a properly fuzzed build matrix gives users real confidence across their compiler, their C++ standard, and their platform; how DevContainers and Compiler Explorer eliminate the local setup barrier for both users and contributors; how the Diátaxis framework turns a documentation site from a reference graveyard into a system that serves newcomers, practitioners, and design-curious contributors; and how to craft an AI contribution policy that manages the rising volume of LLM-generated PRs without sacrificing the architectural integrity that makes a library worth contributing to in the first place.

Whether you are a user evaluating libraries, a developer looking for a C++ project worth your time, or an author trying to build one, you will leave with a concrete, field-tested checklist.