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.

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.

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.

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.

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.

Benchmarks shouldn't live in a different world from tests. Most C++ projects already use Google Test, but the moment performance enters the picture, developers reach for separate tools, separate workflows, and ad-hoc timing loops that don't survive contact with CI. This talk argues for a different default: treat performance measurements as first-class tests. They are written in the same harness, run in the same suite, and fail the same builds.

Using a real C++23 framework built on top of Google Test, the session shows what that looks like in practice. Semantic macros distinguish throughput, latency, and contention tests; built-in statistical analysis tracks medians, percentiles, and coefficient of variation. Adaptive thresholds scale with payload size, so tiny operations and multi-megabyte workloads aren't held to the same stability expectations.

Once benchmarking lives inside the test framework, the rest of the performance toolchain follows. Five CPU profiler backends drop in behind a single --profile flag: perf, gperftools, bpftrace, RAPL, and callgrind. Attaching a memory profile to a test prints bandwidth, efficiency, and a CPU-bound or memory-bound classification with no extra code. The same harness extends to CUDA through a fluent kernel builder that captures launch configuration, achieved occupancy, transfer overhead, multi-GPU scaling efficiency, and thermal throttling. Nsight Compute drops in through the same --profile flag.

The payoff is CI integration that's nearly automatic. A companion CLI tool compares baseline and candidate runs, applies statistical thresholds, posts markdown reports on pull requests, and fails the build on regressions. The result is a single workflow for performance verification that scales from a developer's laptop to a CI runner to a Jetson on a workbench, across hardware ranging from x86 to ARM to RISC-V.

Tooling Track sessions are sponsored by Optiver.

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