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.

In CPython 3.14, we introduced an alternative interpreter implementation. This implementation used [[musttail]] , an experimental C/C++ feature that tells the compiler to enforce tail calls. Against the previous interpreter using computed gotos/switch-case, the new interpreter style shows 2%--15% performance improvement (i.e. geometric mean running time), and is more resilient against certain types of compiler bugs. This feature is already supported by Clang, GCC, and MSVC, and is also the center of a draft proposal targeting C++29. In this talk, I’ll cover the story of getting this feature into the Python interpreter, our collaboration with compiler developers, and the potential wider impact on the C++ community. I’ll also cover interesting use cases of this feature other than for writing interpreters, such as for automatically generating a simple Just in Time (JIT) compiler.

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.

C++ journey doesn’t stop at C++20 where people already started to adopt. C++23 is here, it’s maturing, and it’s packed with new features that deserve your attention. In this session, we’ll explore the most practical, accessible, and impactful additions in C++23 features that you can actually start using, not just in toy projects but in real-world code bases.

We’ll compare C++23 to its predecessors, highlight key language and library improvements, and see how these tools can simplify your development, improve readability, and bring more joy to modern C++.

Whether you're already deep in C++20 or still catching up, this talk will help you chart your course into C++23 with confidence and clarity.

Code review is the most consistent contact point most senior C++ engineers have with the developers they are meant to be growing. It is also the place where well-intentioned mentorship most often turns into gatekeeping, bikeshedding, or a queue of unblocked-but-unlearned junior developers. This talk is about treating code review as a deliberate teaching practice rather than a quality gate that happens to have a comment box attached.

We will start by separating the goals of review: catching defects, enforcing conventions, transferring knowledge, and building the reviewee's judgment. These goals often pull in different directions, and most review comments only serve one of them. We will look at concrete review patterns that teach: asking questions instead of issuing edits, leaving the why alongside the what, distinguishing blocking concerns from preferences, and knowing when to pair on a change in person instead of typing a fifth comment thread.

The middle of the talk will work through real examples from reviewing C++ in production: a tricky lifetime bug, a template that needs to become a function, an overload set that quietly broke at a call site, a refactor that touched more than it should have. For each, we will compare the review comment that unblocks the developer with the review comment that teaches them, and discuss the cost of each choice.

We will close with patterns for the reviewer's own growth. How to notice when you are the bottleneck. How to recognize that the same comment is appearing on every PR and what to do about it — documentation, a lunch-and-learn, a refactor, a linter rule. How to make yourself, eventually, less necessary on your own team. Attendees will leave with specific review techniques they can try the next day, and a way to think about review as a long-running mentorship relationship instead of a per-PR transaction.