CppCon 2026

Reverse-mode automatic differentiation (AD) computes exact gradients with respect to thousands of inputs in roughly the time of a single function evaluation. If you write numerical C++ for finance, scientific computing, or ML and you care about performance, this talk will show you where AD overhead actually comes from and what to do about it.

A straightforward operator-overloading implementation records every arithmetic operation onto a tape and replays it backward to propagate derivatives. On real numerical code this easily introduces 50-100x overhead, and most of that has nothing to do with calculus. It is heap allocation on every operation. It is cache misses walking the tape backward. It is branch mispredictions at memory chunk boundaries. It is recording tape entries for operations where none of the operands are even being differentiated.

We work through a series of C++ techniques that bring this down to around 4x on production code in finance. The two that matter most: a chunked arena allocator with cache-line alignment and branch-prediction hints that turns the recording hot path into a pointer bump and a store, and expression templates that collapse an entire right-hand side into one tape push with all derivatives accumulated in a compile-time-sized stack buffer. We pull up compiler output to show the abstraction really does compile away.

After the big two, we get into the smaller wins that are still worth knowing about: skipping zero adjoints during the backward sweep to exploit sparsity, picking derivative formulas at compile time that reuse the forward result instead of recomputing it, and demoting active-times-passive operations from binary to unary to halve their tape footprint. We also show how a should-record check propagated through the expression tree lets the tape skip entire statements when no operand is active, and how aggressive inlining lets the compiler eliminate these checks entirely for passive subexpressions, so the cost of asking is zero when the answer is no. We benchmark each one in isolation on four numerical workloads ranging from 8 to 161 sensitivities, so you can see what each technique is actually worth.

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.

Many of the problems you encounter in C++ have already been solved, just not by anyone you talk to regularly. Idioms encode best practices into recognizable patterns that help reduce cognitive load, convey intent, and eliminate entire categories of bugs. However, C++ isn’t a single community. It is a language spoken across many industries, including, but not limited to: scientific computing, games, embedded systems, and finance. Each of these domains has developed its own idioms, patterns that are shaped by the specific constraints they face.

While our vernacular evolves independently, the problems they solve often overlap. Consider the convergence around the Curiously Recurring Template Pattern (CRTP) and variant-based dispatch. Embedded systems engineers, working without a heap, paired CRTP with tagged unions to achieve polymorphic behavior over a closed set of types in static storage. Independent of this, high frequency trading firms, driven by latency rather than memory constraints, adopted the same combination to avoid indirect branches and allocator contention. Two communities, two different constraints, but the same pattern. Unfortunately, since each community was solving the problem in isolation, it had to be discovered twice.

This is not a new phenomenon. C++ idioms have been crossing boundaries since at least Coplien’s 1992 work on advanced programming styles. Data-oriented design is making a similar journey today, moving from game engines, where cache-friendly layouts are basically required, to financial systems, where the same CPU architecture imposes the same penalties.

Like a spoken language, C++ evolves not just through formal specification but through usage. New idioms emerge as communities discover better ways to express intent with new or existing features. They grow and spread via conferences, open source libraries, and cross-industry hiring. The C++ Core Guidelines capture some of this evolution, but much of it lives within codebases and communities that you may never find if you don’t look.

This is a call to look for them. We will trace how specific idioms have traveled between industries, examine what made them transferable, and argue that the next improvement to your codebase may already exist, written in a usage of C++ you haven’t learned about yet. While you are at this conference, attend the talks from industries other than your own. You may find a solution in a session that you may otherwise skip.