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.

For the first time in a generation, the C++ Standards Committee has a new convenor. Meet Guy Davidson.

In the decade since joining the Committee, Guy has not personally authored wording that made it into the Standard. Yet, he exemplifies what the role demands: the ability to work intently, iterate relentlessly, absorb setbacks, adapt, and return stronger. He pairs that with a deep commitment to guiding the evolution of a language that underpins much of the modern world – and a rare talent for setting aside ego to build consensus. Sometimes, he even does it in iambic pentameter; at others, in the rhythm of a sea shanty.

In this fireside chat, Guy will reflect on what it means to inherit an institution, his first months in the role, and the moment 118 hands rose in support of C++26 – while Bjarne Stroustrup’s did not. He’ll also share his own work: projects aimed at expanding C++’s capabilities, including an idea inspired by game engine design that has caught the attention of leading climate scientists.

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.