CppCon 2026

The C++ standard is moving more and more in the direction of safety. In the process, the committee is providing us with tools to help make our own code safer.

Many of these tools are specifically around numerics and none of them are enabled by default! To make matters worse, most C++ programmers don't even know these library features exist! Even if they did know, they wouldn't use them, because they are far too wordy.

We're going to do a survey of the relatively recently added new numeric safety related language features and see how they might come together in a real-ish project.

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.

For decades, lock-free programming has been the go-to optimization for the most contended parts of concurrent programs. The reasoning was simple: locks are slow under contention, so eliminate the locks. This made sense on the hardware of the time, and I should know—I've given several talks explaining how and why to do it. The hardware has changed. Modern CPUs are highly optimized for the operations that make locks fast: cache-line transfers, memory ordering, and speculative execution through lock acquisitions. To set the stage, we will briefly establish why, under high contention, a well-written lock consistently outperforms lock-free atomics and CAS loops. (As an aside, I'll hand you a concrete recipe for a spinlock that actually holds up under extreme contention—and show why systematic backoff, by batching cache-line ownership, is what protects the shared interconnect.) But the core of this talk addresses a completely flipped reality: at low contention, lock-free code decisively outperforms spinlocks, for the most surprising reason. Conventional wisdom assumes an uncontended spinlock is practically free. Using raw hardware performance counters, we will see why it isn't: the implicit synchronization a spinlock imposes—even with no contention at all—is deeply unfavorable to modern out-of-order pipelines, while a single lock-free XADD or CAS, an indivisible read-modify-write, is not. The path everyone assumes is free turns out to be the quietly expensive one. Putting these two facts together—locks winning high contention via cache-line batching, atomics winning low contention by staying out of the pipeline's way—points to a concrete design. I will present a highly optimized MPMC (multi-producer, multi-consumer) queue built on a dual-domain structure that deliberately segregates the contended path from the uncontended one, letting each run on the mechanism the hardware actually favors. We will then walk extensive benchmarks across modern silicon—Intel, ARM server (Graviton/Grace), and Apple (M3)—showing this queue is the fastest, often by wide margins, across most operating regimes. We will also see why the tradeoffs play out so differently per chip, in ways that aren't obvious from the spec sheet, and why "ARM vs x86" is the wrong axis entirely—what matters is the chip's target market, not its instruction set. Finally, no benchmark is complete without honest caveats. I will detail the specific corners where this design can still be beaten, the hidden system costs you pay elsewhere to buy this throughput, and why systems that strictly require progress guarantees—deadlock avoidance, priority inversion, safe execution in a signal handler—mean traditional lock-free programming is not dead. It has simply relocated. If you've ever reached for a complex lock-free algorithm to speed up a highly contended hot path—or wondered what your CPU is actually doing during a mutex unlock—this talk will change your mind about where lock-free programming truly belongs.