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.

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.

Software development has now shifted decisively to a distributed, asynchronous paradigm, in which engineers must manage code that may be executing on parallel threads, or on a different machine. Many mainstream programming languages have adapted themselves to this new world. For example, JavaScript has promises and async/await, Python has asyncio, Rust offers zero-cost async/await with compile-time safety, and Go built goroutines and channels as first-class primitives.

C++ developers face the same challenge but have been left without a standard solution. As a result, much production code remains stuck in “callback hell,” where control flow is inverted, error handling is duplicated at every level, and common patterns like "run A and B in parallel, and then combine results" must be hand-rolled every time.

This is not simply a matter of bolting async/await onto C++. Deterministic destruction, zero-overhead abstraction, and precise control over memory and lifetimes, these very properties making C++ powerful dictate that an async framework cannot rely on a garbage collector or managed runtime to paper over complexity. It must earn its place by working with the language's ownership model, not around it.

std::execution is C++’s answer to this problem. Introduced as part of C++ 26, it solves this through composable senders: lazy, type-safe descriptions of work that can be chained, branched, and parallelized before being submitted to an execution context. Like Swift's structured concurrency, std::execution enforces structured lifetimes so that async work cannot silently outlive its scope.

This talk aims to provide application developers with an introduction to the current proposal and give them a grounding in the fundamentals that can be applied in real-world applications. We will walk through several worked examples: from simple chains to parallel fan-out with error propagation, showing side-by-side comparisons with callback-based equivalents to make the advantages more concrete and relatable.

This talk assumes no knowledge of the std::execution framework and no expertise in async programming, though practical, real-world experience will certainly help ground the examples. Attendees will leave with a working understanding of the sender/receiver model, practical patterns they can use, and a clear picture of what structured concurrency means for C++.

In low-latency C++, correctness is table stakes. What separates good systems from great ones is predictability — the ability to hit your deadline not just on average, but at the 99th and 99.9th percentile, where real workloads live. Latency is a feature, and if you don't design for it explicitly, you lose it accidentally.

This talk is a practitioner's guide to writing C++ that behaves predictably under load, drawn from experience building and tuning low-latency systems on Microsoft's Azure Core platform. We start from the mental models that matter most — CPU-centric thinking, the latency stack from L1 to DRAM, and why minimizing work, unpredictability, and memory movement is the foundation of everything else — and then work through the layers of the stack where latency is won or lost in practice.

Through live demos and benchmark data on both x86 and ARM, we'll cover:

STL containers as latency contracts — why most latency bugs start with the wrong container, the real cost of dynamic reallocation, and the measurable wins from reserve() and custom allocators.

Memory layout and cache behavior — struct layout and alignment (and how it differs on x86-64 vs. ARM64), AoS vs. SoA trade-offs, hot/cold data separation, false sharing, NUMA, and TLB pressure.

Atomics vs. mutexes — when atomics actually lose to mutexes, why architecture and memory model dictate the answer, and how to choose between them in real code.

Threading and scheduling — fixed vs. dynamic thread pools, context-switch and migration costs, and why understanding the OS is half the battle.

Benchmarking and observability — why microbenchmarks lie, how to avoid measurement bias and jitter, why latency histograms beat averages, and why "absolute benchmark" is a myth.

You'll leave with a practical playbook for designing and measuring low-latency C++ systems, an honest understanding of why benchmarks from one machine rarely generalize to another, and a sharper instinct for the silent killers — allocations, branches, cache misses, and synchronization primitives — that don't show up in code review but do show up in production.

Teams writing modern C++ libraries with concepts, niebloids, deduction guides, and SFINAE-driven overload sets either accept wrong reference documentation or maintain a Doxygen + XSLT + Sphinx pipeline of workarounds. A different approach is to read C++ from the Clang/LLVM AST, separate corpus extraction from output templates, and recognize common idioms as first-class. This allows the source to stay clean from workarounds.

Doxygen-based pipelines all share these failures on modern C++. Constraint, noexcept, and explicit specifier expressions get truncated or dropped. Niebloids and function objects show as wrappers, not callables. Overloads distinguished by SFINAE or concepts scatter across the output, and CRTP base classes render with the wrong members. All of this disappears when the tool reads the compiler's AST and is able to instantiate specializations.

The talk then covers the architecture of MrDocs, an open-source documentation generator built on Clang/LLVM. Corpus extraction handles the redeclaration, template instantiation, and overload resolution problems that break naive AST traversal. Idiom recognition treats modern patterns as first-class metadata: niebloids, overload sets, concept constraints, requires-clauses preserved verbatim, function-object auto-detection, SFINAE overload sets, and deduction guides. It also captures the specifiers: explicit, noexcept, consteval, storage class, defaulted and deleted functions, and attributes. The templating layer gives full control over the output (HTML, AsciiDoc, Markdown, XML, or custom formats) without forking the tool.

The session is heavy on code from real C++ template libraries, with examples drawn from fmt, nlohmann/json, mp-units, and several Boost and Beman libraries. By the end, you will know why partial AST tools break on modern C++, what an alternative architecture looks like, and which idioms it has to recognize.

Many codebases contain several spots of type punning, and unfortunately a whole lot of those are incorrect and undefined behavior. While many current versions of compilers seem to do the correct thing, they might no longer do that tomorrow. Safety considerations wants to reduce/eliminate UB.

It might be worthwhile to inspect your reinterpret_cast constructs, most probably they are wrong. In this talk we will inspect what is wrong about those, we will learn about alignment, strict aliasing, object lifetime. 3 areas which might flag a red card on our type punning constructions.

Luckily the language evolved and gave us more tools to do it correctly, things like memcpy, memmove, bit cast, start lifetime_as, launder. It does however remain a dark corner and a dangerous territory to wander in. Because let's face it, zero copy is something we love in C++, and those bytes that came from the network, really are an array of integers, array of coordinates, ... Compiler, trust me, I know what I am doing. Am I?

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

Zero-cost abstractions are a foundational idea in C++, promising expressive, high-level code without sacrificing performance. However, developers often encounter unexpected costs when using modern abstractions in practice, even when the code appears idiomatic and well-designed.

This talk explores the assumptions behind zero-cost abstractions and examines what happens when those assumptions no longer hold. Through concrete examples drawn from modern C++ — including ranges and views, type erasure, allocators, and other common abstractions — we will examine how factors such as optimizer visibility, inlining boundaries, allocation behavior, and runtime flexibility influence performance.

This talk treats abstraction as a powerful engineering tool, examining the limits of its zero-cost guarantees in real-world systems. We will look at how seemingly small design choices can introduce hidden costs, why those costs are often difficult to spot through inspection alone, and how to recover performance without abandoning good design or readability.

Attendees will leave with a clearer understanding of when abstractions are truly zero-cost, how to recognize situations where they are not, and how to make informed tradeoffs between expressiveness, flexibility, and performance in modern C++.

Notifiers are a critical synchronization primitive in task-parallel programming systems such as Intel TBB and Taskflow, responsible for efficiently sleeping and waking worker threads as tasks become unavailable and available over and over again, directly impacting scheduler throughput and latency. Correctness here is non-negotiable: a single missed wakeup can significantly hamper the performance of an entire program. Yet writing strong unit tests for notifiers is notoriously difficult, because the bugs they target, lost wakeups, spurious wakes, race conditions, are timing-dependent, non-deterministic, and often only surface under specific thread interleavings that are hard to force reliably.

The problem is compounded in practice. Notifier implementations evolve constantly: small algorithmic tweaks, memory ordering changes, and refactors across systems demand a fresh round of carefully constructed tests. This is tedious, expertise-heavy work that takes a lot of time and engineering effort. In this talk, we explore using Large Language Models (LLMs) to automate the generation of the unit tests for notifiers. Specifically, we will demonstrate how LLM-generated tests, guided by proper prompts can systematically stress the two-phase wait protocol across Notifiers in Taskflow. We will show this in a widely used Notifier implemented in Taskflow. We are able to find an undiscovered bug that has been existing in the project.

From our very first algorithms class, we are taught a simple rule: a better Big-O complexity means a faster algorithm. We spend years mastering asymptotic analysis, memorizing complexity tables, and losing sleep over worst-case scenarios. Big-O becomes a mental shortcut for “good” and “bad” code.

But the real world doesn’t run on whiteboards.

Modern performance is shaped far more by hardware realities than by asymptotic notation alone. CPUs have deep cache hierarchies, wide vector units, speculative execution, and memory systems that punish the “theoretically optimal” solution. GPUs thrive on massive parallelism where simple linear work can outperform asymptotically superior algorithms. Even on regular CPUs, cache-friendly linear scans often beat clever sub-linear approaches that fight memory latency.

In this talk, we will challenge the traditional Big-O mindset. We’ll look at classic algorithms through a modern lens and explore how hardware-aware designs cache-efficient layouts, SIMD/AVX vectorization, and parallel execution models can outperform algorithms with “worse” theoretical complexity. You’ll see why a higher Big-O algorithm can be faster, more scalable, and more predictable in practice.

The goal is not to dismiss Big-O, but to put it back in its proper place: as a tool, not a truth. By the end of this talk, you’ll think differently about performance and start writing code that works with the hardware, not against it.

Much of the public criticism of C++ safety comes from vulnerabilities rooted in C patterns: raw pointer arithmetic, unchecked buffer indices, manual memory management. Modern C++ offers real answers to those problems through RAII, smart pointers, containers, and type-safe abstractions. But C++ also has its own distinct safety issues that have nothing to do with its heritage. Temporary lifetime rules that silently create dangling references. Iterator invalidation semantics that differ across containers in ways even experienced developers get wrong. Smart pointer ownership pitfalls that RAII cannot prevent. Coroutine frames that outlive their captured locals. Implicit conversions that turn a safe string into a dangling view between one line and the next. These are purely C++ problems. They compile cleanly, look correct in code review, and ship to production.

A survey of public CVE reports and security-fix commits across prominent open-source C++ projects shows the same patterns recurring again and again. This talk walks through those patterns, in code that looks correct in review, compiles cleanly, and then breaks at runtime. The session is aimed at intermediate-to-experienced C++ developers who already know modern C++ but want a working catalog of the subtle patterns that ship past typical code review.

Recognizing these patterns has long been the domain of library authors and security researchers. This talk distills a catalog from real-world fixes for everyone else: not a prescriptive standard like the Core Guidelines, but a pattern-recognition toolkit any C++ developer can apply in their next code review. The session also makes the case for expanding the community-level safety conversation to give these C++-unique patterns the same attention as the C-heritage debates.

C++26 reflection was designed so that it could open doors that have been shut since the creation of the language. One of the most firmly bolted doors — type erasure — can be broken down by pushing our new code generation capabilities to their limit. Introducing duck, an open-source library built to harness this new power.

So far, reflection gives us just one function to generate code: define aggregate, which lets you build a simple type. duck uses define aggregate to generate a vtable, transforming a tool for building simple types into one that builds interfaces. You declare an interface as an ordinary struct of C++ function declarations. Plug any type that already has those functions into duck, and you can dynamically call it with plain duck.quack() syntax — no inheritance, adapters, or macros required. This means you can avoid handwriting simply to connect other pieces of code. State what a capability means, and everything you already own that does it is compatible — your types, a vendor's, generated ones, a fifteen-year-old module nobody wants to reopen.

Through this talk, you will learn the basics of code generation with reflection, grounded entirely in real stories from duck's implementation. We'll look at where existing approaches struggle, how duck solves these historic problems, and the central technique: using define_aggregate to both synthesize a vtable and simulate member function call syntax.

We'll end by looking at the future of type erasure: the C++29 proposal for std::protocol, how token injection can perfect the implementation of duck, and how you can help push the frontier of reflection.

C++ library maintainers are often in the dark as to everyone who actually depends on their code. Without that knowledge, deprecation decisions are guesses, the downstream impact of any API change is hard to predict, and the case for funding or continued investment is difficult to make rigorously. This talk demonstrates how mapping your downstream ecosystem changes the way you maintain and evolve a library, using dependent-audit, an open-source tool that discovers real-world dependents by searching public source code for #include directives and CMake integration files, and cross-referencing published academic citations. We'll show concrete examples of what this data reveals: where your true API surface lies, which users are candidates for upstream contribution, and how to make the case for your project's real-world significance. Attendees will leave with a lens for library stewardship built on data and ecosystem analysis

Starting from the simple objective of writing an optimized lexer we will grapple with their fundamental performance factor: branch prediction. We will investigate how lookup tables can improve (or hurt) the CPUs prediction capabilities with some unexpected results. Over time our design evolves by combining parsing and lexing into a single step in a way that is as fast as just a standalone lexer. A central aspect of the design will be a primitive parsing state machine from which the parser source code is generated.

After the talk attendees will have a better understanding of some advanced branch prediction techniques and should have some new ideas for their present or future parsing endeavors.

Years ago while working on a service that would be deployed in Kubernetes, we decided to use the simplest possible TCP based healthcheck. Not because TCP was the right choice, but because implementing a simple HTTP endpoint was more code than it was worth. For our Go services the equivalent HTTP endpoint was only a couple of lines. In fact, we eventually ended up replacing our TCP endpoint with a small Go wrapper around our C++ service.

The Go standard library has done a great job at designing a very ergonomic HTTP library. C++ now has all the right building blocks to express the same design concepts: coroutines, concepts, std::expected, std::jthread. The question is, do these patterns transfer from Go to C++? How do we evaluate the effectiveness of the resulting design?

In this talk I will present a small HTTP library inspired by Go's net/http, built with the tools available in C++23. To evaluate the resulting design I will draw on ideas from Felienne Hermans' The Programmer's Brain and the principle, from Structure and Interpretation of Computer Programs, that API design is language design.

Along the way we'll see which patterns transfer cleanly, which need translation, and why telling the difference is a skill worth developing even if you only work with C++.