CppCon 2026

Software development has now shifted decisively to a distributed, asynchronous paradigm, in which engineers must manage code that may be executing on parallel threads, or on a different machine. Many mainstream programming languages have adapted themselves to this new world. For example, JavaScript has promises and async/await, Python has asyncio, Rust offers zero-cost async/await with compile-time safety, and Go built goroutines and channels as first-class primitives.

C++ developers face the same challenge but have been left without a standard solution. As a result, much production code remains stuck in “callback hell,” where control flow is inverted, error handling is duplicated at every level, and common patterns like "run A and B in parallel, and then combine results" must be hand-rolled every time.

This is not simply a matter of bolting async/await onto C++. Deterministic destruction, zero-overhead abstraction, and precise control over memory and lifetimes, these very properties making C++ powerful dictate that an async framework cannot rely on a garbage collector or managed runtime to paper over complexity. It must earn its place by working with the language's ownership model, not around it.

std::execution is C++’s answer to this problem. Introduced as part of C++ 26, it solves this through composable senders: lazy, type-safe descriptions of work that can be chained, branched, and parallelized before being submitted to an execution context. Like Swift's structured concurrency, std::execution enforces structured lifetimes so that async work cannot silently outlive its scope.

This talk aims to provide application developers with an introduction to the current proposal and give them a grounding in the fundamentals that can be applied in real-world applications. We will walk through several worked examples: from simple chains to parallel fan-out with error propagation, showing side-by-side comparisons with callback-based equivalents to make the advantages more concrete and relatable.

This talk assumes no knowledge of the std::execution framework and no expertise in async programming, though practical, real-world experience will certainly help ground the examples. Attendees will leave with a working understanding of the sender/receiver model, practical patterns they can use, and a clear picture of what structured concurrency means for C++.

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.

Tooling Track sessions are sponsored by Optiver.

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.

Tooling Track sessions are sponsored by Optiver.

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.

From our very first algorithms class, we are taught a simple rule: a better Big-O complexity means a faster algorithm. We spend years mastering asymptotic analysis, memorizing complexity tables, and losing sleep over worst-case scenarios. Big-O becomes a mental shortcut for “good” and “bad” code.

But the real world doesn’t run on whiteboards.

Modern performance is shaped far more by hardware realities than by asymptotic notation alone. CPUs have deep cache hierarchies, wide vector units, speculative execution, and memory systems that punish the “theoretically optimal” solution. GPUs thrive on massive parallelism where simple linear work can outperform asymptotically superior algorithms. Even on regular CPUs, cache-friendly linear scans often beat clever sub-linear approaches that fight memory latency.

In this talk, we will challenge the traditional Big-O mindset. We’ll look at classic algorithms through a modern lens and explore how hardware-aware designs cache-efficient layouts, SIMD/AVX vectorization, and parallel execution models can outperform algorithms with “worse” theoretical complexity. You’ll see why a higher Big-O algorithm can be faster, more scalable, and more predictable in practice.

The goal is not to dismiss Big-O, but to put it back in its proper place: as a tool, not a truth. By the end of this talk, you’ll think differently about performance and start writing code that works with the hardware, not against it.

Much of the public criticism of C++ safety comes from vulnerabilities rooted in C patterns: raw pointer arithmetic, unchecked buffer indices, manual memory management. Modern C++ offers real answers to those problems through RAII, smart pointers, containers, and type-safe abstractions. But C++ also has its own distinct safety issues that have nothing to do with its heritage. Temporary lifetime rules that silently create dangling references. Iterator invalidation semantics that differ across containers in ways even experienced developers get wrong. Smart pointer ownership pitfalls that RAII cannot prevent. Coroutine frames that outlive their captured locals. Implicit conversions that turn a safe string into a dangling view between one line and the next. These are purely C++ problems. They compile cleanly, look correct in code review, and ship to production.

A survey of public CVE reports and security-fix commits across prominent open-source C++ projects shows the same patterns recurring again and again. This talk walks through those patterns, in code that looks correct in review, compiles cleanly, and then breaks at runtime. The session is aimed at intermediate-to-experienced C++ developers who already know modern C++ but want a working catalog of the subtle patterns that ship past typical code review.

Recognizing these patterns has long been the domain of library authors and security researchers. This talk distills a catalog from real-world fixes for everyone else: not a prescriptive standard like the Core Guidelines, but a pattern-recognition toolkit any C++ developer can apply in their next code review. The session also makes the case for expanding the community-level safety conversation to give these C++-unique patterns the same attention as the C-heritage debates.

For the first time in a generation, the C++ Standards Committee has a new convenor. Meet Guy Davidson.

In the decade since joining the Committee, Guy has not personally authored wording that made it into the Standard. Yet, he exemplifies what the role demands: the ability to work intently, iterate relentlessly, absorb setbacks, adapt, and return stronger. He pairs that with a deep commitment to guiding the evolution of a language that underpins much of the modern world – and a rare talent for setting aside ego to build consensus. Sometimes, he even does it in iambic pentameter; at others, in the rhythm of a sea shanty.

In this fireside chat, Guy will reflect on what it means to inherit an institution, his first months in the role, and the moment 118 hands rose in support of C++26 – while Bjarne Stroustrup’s did not. He’ll also share his own work: projects aimed at expanding C++’s capabilities, including an idea inspired by game engine design that has caught the attention of leading climate scientists.