CppCon 2026

Python's Global Interpreter Lock, which determines which single thread can execute native Python code and call C API functions, simplifies writing multithreaded code. By default, the most popular C++ bindings to this API, pybind11 and Cython, implicitly enables the GIL by default. However, sticking with this execution model leaves out extra performance afforded by modern multicore CPUs with hyperthreading, as automatic locking and unlocking of the GIL does not scale well with thread counts, especially in performance-sensitive workloads.

The newfangled free-threaded interpreter promises salvation when running either pure Python code or with compiled extensions. General multithreading rules apply (prefer thread-local variables, using locks to prevent simultaneous access of shared data), but when dealing with projects containing compiled extensions that directly or indirectly interface with Python's C API, more porting rules also apply.

Key porting tips, including projects using the Limited API, include: port native code away from C API functions that avoid borrowed references because they aren't thread-safe; modify unit tests to catch concurrency bugs arising from assuming the presence of the GIL; and extend CI coverage of Python interpreters both for testing and to build free-threaded compatible wheels.

Tooling Track sessions are sponsored by Optiver.

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.

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.

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

Range views enable a "no raw loops" style of programming — not as a matter of taste, but as a pragmatic way to reuse well-tested algorithms to write code faster, express intent clearly, and avoid common bugs. In practice, however, developers often run into issues that may lead them to abandon ranges altogether: - unintuitive behavior and surprising limitations - slower compilation and runtime performance compared to raw loops - high complexity when implementing custom views

In this talk, we'll distill the core design choices behind these problems — and the alternatives that avoid them. In particular, we'll compare: - iterators and indices - external and internal iteration - transformations of nested views that overcome limitations of internal iteration

Attendees will leave with practical insights for designing and using range abstractions, along with examples of libraries that embody these ideas.

Every mature codebase carries history and technical debt. The challenge is modernizing without stopping the world or introducing big re-write failure risks.

In this talk, we’ll explore how to modernize legacy C++ codebases incrementally using a mix of deterministic code transformations and AI-assisted refactoring .

After delving into some of the common problems with legacy modernization, we'll start tackling the simple "boring" stuff that deliver huge leverage of changes via clang tooling . These represent repeatable, deterministic reviewable upgrades that can be automated and applied at scale.

Then we can look at more difficult transformations that can be AI assisted with more aggressive transformations including API improvements and how to prevent it going off the rails. This will be backed by Compiler diagnostics, static analysis and testing to keep changes maintainable and correct .

The goal is not to replace engineering judgment, but to accelerate it: turning modernization into a continuous, low-risk workflow instead of a disruptive project.

Attendees will leave with a repeatable playbook for modernizing legacy codebases incrementally, safely, and at scale—using the right tool for each class of change

Tooling Track sessions are sponsored by Optiver.

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++.