CppCon 2026

In C++, monadic operations are a commonly utilized API for interacting with result types like std::optional and std::expected. By chaining the computations, these abstractions allow you to manipulate the underlying values using less boilerplate code. Monadic operations are a powerful tool suitable for a variety of usage scenarios. They enhance code robustness and significantly lower the risk of accidental errors.

Despite its benefits, many users consider the syntax of monadic operations to be overly verbose, and the underlying concept often seems complicated. There are also the cases where the restrictions placed on functions require using extra statements, specific return and arguments types, and reduce code readability. However, are there other options available? Do we have promising alternatives? The short answer is: yes. While C++ does not yet include pattern matching as a native language feature, the standard library still offers tools for achieving many useful pattern-matching-like functionalities. We will explore how to apply std::visit to this problem and evaluate if an abstraction, which we might call std::match, could serve as an effective substitute for monadic operations in various situations.

Based on several years of practical production experience, this talk will explore the use of monadic result type interfaces and comparable alternatives. This information will benefit practicing software engineers looking to deepen their understanding of these features and integrate them into their codebases.

Production C++ code often hides small but deeply complex algorithms inside layers of engineering: APIs, lifetimes, error handling, integration, logging, and glue code. We test classes and systems, but rarely the algorithm itself in isolation.

Off-by-one errors and broken or missing invariants can survive extensive pre-production testing. Line coverage does not imply branch coverage. Branch coverage does not imply coverage of algorithmic corner cases. Testing through a wide public API often obscures the mathematical structure of the problem, making subtle bugs difficult to discover through multiple layers of abstraction.

This talk explores how to extract an "algorithmic core" from a larger component. Its correctness is fundamentally mathematical and largely language-agnostic rather than C++-specific.

Using examples such as substring matching, topological sorting variations, and lazy evaluation on trees, we will examine how problem corner cases differ from implementation corner cases, and how easily some of them are skipped.

We will discuss:

• Recognizing when an algorithm is entangled with boilerplate
• Extracting core logic without introducing accidental complexity
• What it takes to test algorithmic code in isolation
• Raising the level of abstraction to make reasoning easier without merely relocating complexity
• Using LLMs to assist in exploring and validating implementations
• Gradual rollout and comparison of competing implementations

There is no classical treatise on the design and implementation build systems; no faithful textbook every toolchain engineer has on their bookshelf. If there were we would need to throw it out anyway, because C++20 modules required a significant rethink of how build systems orchestrate compilation of C++ software.

It's been said over and over again that C++20 modules complicate the classic compile and link steps for C++. However, few have dived into how exactly build systems are dealing with this step-change in complexity. Talks will demo a few raw compiler invocations and say no more about the subject. This leaves engineers unequipped to deal with problems that arise in their builds; frustrated by opaque error messages and baffling build logs.

In this talk, we're going to fill in the rest of the blanks and explore exactly how build systems are tackling modules.

Are you smarter than a branch predictor? In this interactive, game-show themed session, the audience becomes the branch predictor: participants vote on which of two C++ snippets will run faster before we examine what actually happens on real hardware. The snippets are drawn from real world production code, and correct answers are rewarded with stress balls. Through these examples, we build a practical mental model of how modern CPUs handle control flow, and why even small branching decisions can have a significant impact on performance. A single mispredicted branch can stall a CPU pipeline for dozens of cycles, making control flow a hidden bottleneck in performance-critical systems. Using annotated assembly, performance counter data, and cross-platform comparisons, this talk explores branch prediction, misprediction costs, indirect calls and virtual dispatch, and the trade-offs between branches and conditional moves. We examine how compilers (GCC, Clang, MSVC) transform code under different optimization levels (such as -O2 and -O3), and highlight non-obvious cases where “branchless” code performs worse or behaves differently across architectures. The examples are intentionally small micro-benchmarks, but each exposes patterns that appear in real-world systems when control flow becomes the bottleneck. The session also covers how to design trustworthy micro-benchmarks and validate performance changes using hardware counters. Attendees will leave with a clearer understanding of how branches behave on modern processors, when to rely on compiler optimizations, and when to measure and optimize manually.