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.

Modern programming languages offer powerful tools for creating intuitive, expressive code, but few are as frequently debated as function and operator overloading. While these features allow developers to write code that mimics natural mathematical notation, such as A+B for complex numbers or vectors, they also introduce significant risks of ambiguity, hidden performance costs, and unintuitive behavior if misused.

This talk explores the balance between expressive power and code maintainability. We will dive into the mechanics of compile-time polymorphism, examining how compilers resolve overloaded calls and the strict rules governing arity, precedence, and associativity. Beyond the what and the how, we will talk about the when and the why with examples.

How far can modern C++ push an emulator before performance stops being a C++ problem and becomes a systems problem? This talk is the final part of a CppCon trilogy about building an extremely fast Game Boy emulator in modern C++, moving from high-performance emulation techniques to the limits imposed by hardware, compilers, and CPU architecture.

The target is intentionally absurd but not arbitrary: a Game Boy emulator running Tetris at roughly 100 times original speed, about 6,000 frames per second. However, the goal is not to support every Game Boy cartridge ever made. This project deliberately specializes for one iconic game first, using the code paths Tetris actually exercises as a guide, while keeping enough design discipline to test other games later. That means questioning the architecture of the emulator itself: instruction dispatch, memory access, generated code size, cache behavior, branch prediction, compile-time computation, benchmarking methodology, and the tension between accuracy, maintainability, flexibility, and raw throughput.

This is not a victory-lap performance talk. It is a measurement-driven engineering investigation. Rather than treating 6,000 FPS as just a headline number, this talk treats it as a stress test: a way to force difficult design decisions into the open. Attendees will leave with concrete lessons about performance-oriented C++: how to measure methodically, how to specialize without losing control, how to reason about modern CPU behavior, and how to decide when an optimization is worth its cost.