CppCon 2026

To write the best C++ application code, you must think like a library author. This talk reframes application development as a form of library design, where every component is a potential asset for future maintenance and extension.

We'll survey the C++ language features that empower library authors to create powerful, flexible, and safe abstractions. From there, we'll distill the 'library author mindset.’ You will leave with concrete principles and techniques to make your application code more modular, maintainable, composable, reusable, testable, and ultimately, more valuable.

How to Choose and Use the Right Container in Modern C++: Part 1, Classic Containers

Choosing the right container and using it correctly can have a profound impact on the performance of a program, but doing so is harder than you might think. In Part 1 we will survey the containers and adaptors in the C++17 Standard Library, and discuss how to choose the best tool for the job and extract the best performance from it. We will consider the abstractions they model and the practical limitations they impose, and find that choosing between them requires an understanding not only of the speed and size tradeoffs of each container, but also of the difference between algorithmic complexity and actual behavior. And we will flag aspects of the standard containers that, without this understanding, can lead you to the wrong choice.

How to Choose and Use the Right Container in Modern C++: Part 2, New and Future Containers

Choosing the right container and using it correctly can have a profound impact on the performance of a program, but doing so is harder than you might think. In Part 2 we will survey the new containers and adaptors introduced to the Standard Library in C++23/26, and discuss how to choose the best tool for the job and extract the best performance from it. We will consider the abstractions they model and the practical limitations they impose, and find that choosing between them requires an understanding not only of the speed and size tradeoffs of each container, but also of the difference between algorithmic complexity and actual behavior. And we will examine a proposal for a future container that diverges from the historical STL design principles and ask: what makes for a good container design?

To navigate safely, a robot must simultaneously ingest high-frequency sensor data, compute complex spatial algorithms, and publish control commands. Historically, frameworks like ROS 2 have handled this via asynchronous callbacks. However, as autonomous stacks scale, relying heavily on unstructured callbacks can obscure control flow, making state synchronization difficult and robust task cancellation notoriously complex.

This talk explores how to transform unstructured, callback-based architectures in a robotics navigation stack into declarative pipelines using structured concurrency (specifically, C++ Senders and Receivers via stdexec). Attendees will dive into two real-world architectural examples: a collision monitor and a waypoint follower, showcasing readable logic pipelines, thread-hopping between an event loop and a static thread pool, and clean task cancellation.

Why does 0.1 + 0.2 not equal 0.3? Because binary floating-point cannot exactly represent most decimal fractions, the value 0.1 simply does not exist in IEEE 754 binary. For applications where rounding errors are unacceptable, finance, billing, regulatory reporting, scientific data interchange, this is a structural problem, not a precision setting that can be tuned away. IEEE 754-2008 introduced a decimal floating-point alternative that stores the significand in base 10, and ISO/IEC TR 24733 sketched a C++ binding for it. Compiler support, however, has remained uneven across vendors and architectures.

Boost.Decimal is a header-only, dependency-free, C++14 implementation of IEEE 754-2008 and TR 24733 decimal floating-point. It provides three IEEE-conformant types, decimal32 t, decimal64 t, and decimal128 t, and three companion decimal fast* t types that trade strict bit-layout conformance for speed where you don't need on-the-wire interoperability. All six types behave like built-in floating-point: they're constexpr-friendly throughout, support mixed arithmetic and promotion, and ship with their own implementations of , , , , , hashing, , and Boost.Math integration. The library is tested natively on x86 64, ARM64, and s390x, and under emulation on PPC64LE and ARM Cortex-M.

This talk is the introduction to decimal floating-point that most C++ programmers never got. We'll cover what decimal floating-point actually is at the bit level (BID vs. DPD encodings, the cohort concept that has no analogue in binary), why the standard library's defaults are what they are (e.g. Rounding), and how Boost.Decimal's API maps onto familiar and patterns. We'll work through worked examples, parsing a price feed, computing financial summary statistics through Boost.Math, round-tripping values through while preserving cohort information, and walk through the library's deliberate deviations from both IEEE 754 and the C++ standard, including why floating-point exception flags were sacrificed to keep constexpr and how from_chars was extended to distinguish overflow from underflow as well as preserve cohorts. We'll close with reviews of the benchmarks versus binary floating point, as well as other existing libraries.

By the end, attendees will know when reaching for decimal is the right call, which of the six types fits their workload, and what trade-offs the library made on their behalf.

C++ lifetime management is fundamentally built around synchronous scope exit. Constructors establish invariants, destructors release resources, and RAII permits ownership and cleanup to compose naturally with ordinary control flow. Asynchronous systems disrupt this model. Destruction may itself require asynchronous work, and “just launch another task in the destructor” quickly turns deterministic lifetime management into unstructured background activity.

This talk explores the implementation of async lifetime management in std::execution, based on the enter/exit scope sender framework proposed in P3955. Rather than treating async construction and destruction as special cases, the model reframes them as composable asynchronous protocols built around explicit async scope entry and exit operations. The talk follows the process of turning these ideas into working code, beginning from the low-level enter/exit sender abstractions and progressively assembling higher-level lifetime facilities on top. Along the way, the implementation uncovers an important self-similarity in the problem domain: Higher-level async lifetime facilities can themselves be expressed in terms of the same lower-level async lifetime primitives.

The implementation discussion focuses on the machinery required to make these guarantees real: Coordinating async teardown within structured concurrency, managing partially-entered scopes, and preserving deterministic cleanup semantics even when destruction itself becomes asynchronous. The resulting design serves both as a practical exploration of async lifetime management and as a case study in how implementing an abstraction can reveal deeper structural properties hiding inside the model itself.

Every mature codebase carries history and technical debt. The challenge is modernizing without stopping the world or introducing big re-write failure risks.

In this talk, we’ll explore how to modernize legacy C++ codebases incrementally using a mix of deterministic code transformations and AI-assisted refactoring .

After delving into some of the common problems with legacy modernization, we'll start tackling the simple "boring" stuff that deliver huge leverage of changes via clang tooling . These represent repeatable, deterministic reviewable upgrades that can be automated and applied at scale.

Then we can look at more difficult transformations that can be AI assisted with more aggressive transformations including API improvements and how to prevent it going off the rails. This will be backed by Compiler diagnostics, static analysis and testing to keep changes maintainable and correct .

The goal is not to replace engineering judgment, but to accelerate it: turning modernization into a continuous, low-risk workflow instead of a disruptive project.

Attendees will leave with a repeatable playbook for modernizing legacy codebases incrementally, safely, and at scale—using the right tool for each class of change

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.