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.

Choosing the right Standard Library container and using it correctly can have a profound impact on the performance of a program, but what may appear to be the obvious choice can turn out to be the wrong one. In this two-part series we will explore the abstractions each container models and the practical limitations it imposes. We will see that choosing between them requires an understanding not only of the speed and size tradeoffs of each container, but also of the difference between algorithmic complexity and actual behavior. Our goal will be to learn how to choose the right tool for the job and extract the best performance from it.

In Part 1 we will survey the containers and adaptors in the classic STL, including the additions introduced in C++11. Along the way we will investigate some premises underlying the original C++98 STL design that often lead to the wrong choice today.

In Part 2 we will examine a C++17 improvement to the associative containers and the powerful new containers and adaptors that C++23 and C++26 provide. We will finish with a discussion of a proposed future container that deliberately diverges from the original STL design principles while addressing several limitations of the current sequence containers.

Choosing the right Standard Library container and using it correctly can have a profound impact on the performance of a program, but what may appear to be the obvious choice can turn out to be the wrong one. In this two-part series we will explore the abstractions each container models and the practical limitations it imposes. We will see that choosing between them requires an understanding not only of the speed and size tradeoffs of each container, but also of the difference between algorithmic complexity and actual behavior. Our goal will be to learn how to choose the right tool for the job and extract the best performance from it.

In Part 1 we will survey the containers and adaptors in the classic STL, including the additions introduced in C++11. Along the way we will investigate some premises underlying the original C++98 STL design that often lead to the wrong choice today.

In Part 2 we will examine a C++17 improvement to the associative containers and the powerful new containers and adaptors that C++23 and C++26 provide. We will finish with a discussion of a proposed future container that deliberately diverges from the original STL design principles while addressing several limitations of the current sequence containers.

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.