CppCon 2026

Memory leaks are very hard to treat. We have reliable tools like valgrind or AddressSanitizer to tell us whether or not an application has leaked memory, but current tools cannot tell us where the leak happens (they can tell us where the allocation happened,which is not the same).

I show that it is possible to run an analysis that is equivalent to running a garbage detection pass after every instruction and use that to find the actual cause of memory leaks in open source applications.

Using a garbage detection algorithm on record-and-replay recording, one can overcome the most obvious obstacle: stopping a program a program after every instruction or running garbage detection algorithms is very slow, but we can effectively run a bisection search on the recorded timeline to avoid having to evaluate after every instruction.

The goal is attribution to source code. Are we limited to reporting the instruction that overwrites the last reference to allocated memory or can we actually diagnose a specific error for a concrete function?

Every C++ developer runs their build system dozens of times a day, yet few think about what it actually computes. Underneath every cmake --build or ninja invocation lies a directed acyclic graph, a DAG of dependencies that determines what gets rebuilt, in what order, and how much parallelism is available. When builds are slow, when incremental rebuilds trigger more work than expected, or when CI bottlenecks in surprising places, the root cause is almost always a structural property of this graph. Most developers never look at it.

This talk makes the build graph visible and actionable. Through curated examples, we will visualize dependency graphs and expose the common pathologies: overly connected "hub" headers that invalidate half the build when touched, deep critical paths that starve parallelism even on a 128-core machine, and accidental edges introduced by includes that no one questioned. These are not just build performance issues: they are architectural issues wearing a different hat. Your build graph is the ground truth of your codebase's structure, whether or not it matches the diagram in your team's documentation.

Armed with this mental model, we will walk through practical techniques for reshaping the graph: measuring critical path length from .ninja_log , identifying high-fan-in nodes, breaking costly edges with forward declarations and interface segregation, and using graph analysis as an automated architectural fitness function in CI. Worked examples will show concrete before-and-after measurements. You will leave with a new way of seeing your codebase, not as files in folders, but as a graph you can visualize, measure, and deliberately reshape.

Modern C++ development spans platforms, build systems, and increasingly complex project structures. In this landscape, Visual Studio Code has carved out its distinct position as a lightweight, extensible editor that works where you do, with first-class extensions built on decades of C++ language services and build system integration. This year's update deepens both of those foundations and opens them up to AI-driven workflows powered by GitHub Copilot.

This session walks through what's new across three dimensions of C++ development in Visual Studio Code. For the inner loop, we'll cover practical improvements to everyday compile-test workflows, including CMake target bookmarks and Run Without Debugging. For writing and understanding code, we'll show how the C/C++ extension's language services now surface rich project understanding to GitHub Copilot, giving AI assistance real awareness of your code structure instead of relying on generic pattern matching. For your workflow, we'll demonstrate how AI capabilities compose across different modes of working: inline suggestions for hands-on editing, agent coordination for multi-file refactoring, and CLI sessions for long-running tasks and deeper codebase analysis you can revisit on your own schedule.

Throughout the session, we’ll use real-world C++ problems to demonstrate where these tools meaningfully improve productivity and where they intentionally stay out of your way. Finally, we’ll show you how to inform GitHub Copilot about your team's best practices and scale them across your code through extensibility points like skills, custom instructions, and custom agents.

In many languages, you can mock almost anything. Python has unittest.mock, Java has Mockito and PowerMock, and C# has Moq. In C++, you can usually mock only what was designed to be mockable — and little else. Want to mock a free function? Wrap it in an interface. A static method? Refactor to a template. A non-virtual member? Redesign the class hierarchy. The cost is real: developers either shape production code around testing-tool constraints instead of domain needs, or they simply leave hard-to-mock code untested.

This talk introduces [LibraryName], a new C++ mocking library we developed (and plan to publish soon as open source) that can mock almost any C++ callable — free functions, static methods, non-virtual members, private members, templates, lambdas, and even extern "C" routines — without modifying the code under test. Developed and battle-tested at [CompanyName] for three years across a very large C++/C codebase, it aims to deliver a first-class testing experience for C++. Under the hood it uses runtime binary patching — replacing function prologues with redirections at test time, restoring them on scope exit — all surfaced through familiar Google Mock syntax.

We'll show [LibraryName] in action, walk through the patching mechanism, and share how to get started -- you'll walk away ready to test almost any function, regardless of how it was designed. Strong test coverage has always been essential, and AI-assisted code generation only increases the need for reliable testing backpressure. C++ deserves mocking tooling that matches.

Clang is the C++ compiler used by hundreds of millions of developers every day, yet most of those developers have never looked inside it. The codebase can feel intimidating, with millions of lines of C++, an unfamiliar architecture, and a review process with its own customs. But once you know the map, contributing is surprisingly accessible.

This session is a live, code-first walkthrough of the full contribution cycle for Clang. Starting from a clone of the LLVM monorepo, we will configure a development build, locate the right subsystem for a real reported bug, write a regression test, fix the bug, and verify the fix. We will then extend that foundation to implement a small but complete language feature: adding a new diagnostic, walking through Sema, the AST, and the diagnostic engine as we go. Every step attendees see on screen can be replicated on their own laptops during and after the session.

Attendees will leave with a mental model of Clang's layered architecture (driver, frontend, Sema, CodeGen), a workflow for finding the code responsible for any given compiler behavior, and enough familiarity with the test infrastructure and review process to open their first pull request.

AI agents are accelerating code generation at an unprecedented pace, yet C++ file is still compiled as a monolithic translation unit, meaning a many-core machine often cannot rebuild a template-heavy file much faster than a single core. Header-heavy designs, inline functions, and templates compound the problem: the same bodies are parsed repeatedly, and small edits can invalidate an entire translation unit.

This talk presents a compiler-agnostic technique for splitting translation units into smaller independently compilable units. Using libclang, the tool rewrites headers and sources into declaration-only interfaces plus generated .cpp fragments, backed by a shared preamble that can turn into a C++ module, precompiled header, cached serialized AST and a source-map. The fragments compile in parallel, then link into a binary functionally equivalent to the original monolithic build.

Expect benchmarks from major codebases covering compile-time, link-time, and run-time performance; live demos of fast incremental updates that avoid reprocessing unchanged code as well as an analysis of the resulting binaries layout.

Modern C++ development has embraced package managers like Conan and vcpkg for dependency management, gaining reproducibility and productivity. However, a significant weak point remains: the build toolchain. Unlike standard dependencies, the disparate set of tools comprising the compiler, linker, standard libraries, and OS-specific headers often remains outside this managed ecosystem. This gap leads to frequent complications, where misaligned versions between local environments and CI cause build errors and subtle ABI incompatibilities.

The operational cost of maintaining these toolchains is high. Updating a compiler version often necessitates the creation and deployment of new VM images or manual infrastructure updates, a process that can be even more complex if specialized environments like CUDA are involved. These hurdles directly impact engineering productivity and organizational alignment. Docker is a popular solution to isolate toolchains, but it does not support all the mainstream platforms.

This talk proposes a shift in perspective: treating the build toolchain as just another dependency. We will explore how leveraging toolchain isolation allows developers to express specific toolchain versions within their project manifests—using cross-platform tools like Conan and vcpkg to ensure strict repeatability across local developer environments and CI machines.By automating the fetching and configuration of the entire compiler suite, teams can ensure perfect alignment across all environments, simplify the upgrade path, and ultimately boost engineering velocity.

The C++ Core Guidelines is quickly gaining popularity as the main C++ coding standard in the industry. The official introduction of the standard states the following: "Many of the rules are designed to be supported by an analysis tool. One way of thinking about these guidelines is as a specification for tools that happens to be readable by humans."

We took up this challenge: we built the tools, implemented a subset of the C++ Core Guidelines, and applied them to more than 8,000 industrial embedded software projects. That was not an easy undertaking, because the defined “rule enforcements” contain all kinds of caveats, shortcomings, unclarities, exceptions etc.

During this talk, we will explore the conceptual obstacles we encountered during implementation, how we have addressed them, and what remains to be done to make the C++ Core Guidelines the de facto standard in C++ programming.

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.

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.

Language bindings for C++ can be valuable tools for developers who wish to make C++ libraries available for use in other programming languages, like Python. There are many reasons developers may wish to do this, including testing, prototyping, or performance.

One of the issues often faced when writing bindings for C++ is the need to write excessive amounts of boilerplate code to bridge the gap between the C++ types and interfaces and their equivalents in other languages.

Building on previous presentations, this talk will not just explore how you can use Reflection in C++26 to generate the necessary binding code, but also how you can integrate this into a CMake-based build system to enable the automatic generation of bindings for existing classes or libraries with minimal additions. We will present real-world examples, primarily using Python, to show how language bindings can be automatically generated, but we also show how this can be extended to other languages.

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