CppCon 2026

Are you smarter than a branch predictor? In this interactive, game-show-themed session, the audience becomes the branch predictor: participants vote on which of two C++ snippets will run faster before we examine what actually happens on real hardware. The snippets are drawn from real-world production code, and correct answers are rewarded with unique specialty erasers (no two are the same!). Through these examples, we build a practical mental model of how modern CPUs handle control flow and why even small branching decisions can have a significant impact on performance. Using annotated assembly, performance-counter data, and cross-platform comparisons, this talk explores branch prediction, misprediction costs, indirect calls and virtual dispatch, and the trade-offs between branches and conditional moves. We examine how different compilers (GCC, Clang, and MSVC) transform code and highlight non-obvious cases where “branchless” code performs worse or behaves differently across architectures. The examples are intentionally small microbenchmarks, but each exposes patterns that appear in real-world systems when control flow becomes the bottleneck. Whether you're a systems engineer or just curious about what your branch predictor is doing behind your back, this session will give you a concrete mental model of control flow. You'll leave with the tools to profile your code, interpret assembly, and make informed decisions about when to rely on compiler heuristics versus manual optimization.

C++26 introduces contract assertions: language-level constructs for expressing expectations about program correctness, optionally checking them at runtime, and configuring how violations are handled. However, what ships in C++26 is intentionally minimal — not the final destination, but a carefully designed foundation for a much more capable facility.

In this talk, we begin with a brief overview of contract assertions as they exist in C++26, including the three kinds of assertions ( pre , post , and contract_assert ), the four evaluation semantics ( ignore , observe , enforce , and quick-enforce ), and the user-replaceable contract-violation handler. The focus of the talk, however, is the next stage of evolution already underway.

We will explore the major extensions currently planned for C++29 and beyond, and the problems they are intended to address, and how they build upon the extensibility intentionally designed into the C++26 facility. Many of the concerns raised during standardisation — particularly around scalability, configurability, and expressiveness — are already being addressed by these extensions. We will discuss contract assertions on virtual functions; grouping contract assertions and configuring evaluation semantics by group; constraining evaluation semantics (for example, assertions that must always or never be enforced); postconditions that refer to earlier program state; user-defined diagnostic messages; and finally, compiler-generated, implicit contract assertions guarding against core-language undefined behavior. We then look even further ahead at more ambitious ideas still in earlier stages of exploration: class invariants, contracts on function pointers, and procedural interfaces.

Rather than just listing the proposed extensions, we will examine the design considerations behind them and show how the new functionality fits into the broader model of contract assertions in C++. What does it mean for contracts to participate in virtual dispatch? When can contract assertions support optimisation? How can evaluation semantics remain both predictable and configurable across large codebases? Understanding these questions is essential to understanding where contract assertions in C++ are heading next.

This talk is intended for anyone interested not only in how contract assertions work in C++, but also in the principles shaping their future evolution — and what a complete contract facility for C++ might ultimately look like.

For thirty years, SIMD has been the preserve of experts. Writing the fastest C++ has meant hand-written intrinsics, locking code to one architecture, and parallel implementations maintained across every instruction set you ship to. Auto-vectorization can help, but optimizers may give up in complex scenarios where iteration independence isn't obvious. C++26 changes that by putting SIMD in the hands of every C++ programmer, bringing portable, expressive data parallelism into the standard library.

For the engineers who have spent decades writing intrinsics in telecoms, finance, HPC, and embedded systems, migration to std::simd is only worthwhile if it preserves the performance they have fought to achieve. Every cycle counts when code runs tens of thousands of times per second, for years on end, and a portable abstraction that costs ten percent is not a win. The bar for adoption is therefore high: the abstraction must be measurably cheap, the generated code must match hand-written intrinsics, and the tricks and techniques those engineers rely on must all be expressible in the library, not lost in translation.

This talk takes the practitioner's view, aimed squarely at the engineers who write real intrinsics code today and need to know whether std::simd can replace it. It starts with what modern SIMD hardware actually offers, grounding std::simd in real silicon. It then works through the main features of C++26's std::simd with worked examples drawn from the patterns that recur in production intrinsics code, accessible to programmers new to the library and detailed enough for intrinsics veterans to map against their own kernels with all their accumulated tricks and techniques. A look under the hood at our implementation shows how careful API design and aggressive use of hardware features make the abstraction as cheap as the target architecture allows, and how the library fills the gaps on weaker targets with implementations that an expert library author can write once on behalf of every user. The talk closes with a preview of the C++29 proposals being written now to close the remaining gaps, so that std::simd becomes a clear win even for the most performance-critical code.

You found the perfect C++ library. But you cannot integrate it with your CMake build without reading three pages of bespoke instructions. The documentation (if any) is a Doxygen-generated API dump. You file a bug, get "read the source," and move on. You never adopted it—and you had every intention of doing so.

Or you are the author of that library. Technically brilliant. Six months after release: three users, no contributors, two support tickets, you are not sure how to answer. Drawing on years of experience as both a maintainer of mp-units — a high-visibility, standards-track C++ library — and as a developer who regularly evaluates and contributes to third-party C++ projects, I have watched this pattern repeat across dozens of technically excellent libraries. The barriers that drive users away, frustrate potential contributors, and quietly kill great projects are predictable. More importantly, they are fixable.

This talk traces the five stages every C++ library must survive — Discovery, Evaluation, Integration, Contribution, and Community — and examines the concrete engineering decisions at each. We will look at how naming, README structure, and CI signals communicate trust to a user who found you three seconds ago; how a properly fuzzed build matrix gives users real confidence across their compiler, their C++ standard, and their platform; how DevContainers and Compiler Explorer eliminate the local setup barrier for both users and contributors; how the Diátaxis framework turns a documentation site from a reference graveyard into a system that serves newcomers, practitioners, and design-curious contributors; and how to craft an AI contribution policy that manages the rising volume of LLM-generated PRs without sacrificing the architectural integrity that makes a library worth contributing to in the first place.

Whether you are a user evaluating libraries, a developer looking for a C++ project worth your time, or an author trying to build one, you will leave with a concrete, field-tested checklist.

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.

Tooling Track sessions are sponsored by Optiver.

At scale, writing C++ becomes a different engineering discipline. Problems that appear secondary in smaller systems — dependency boundaries, build graph stability, toolchain inconsistencies, integration latency, ownership, and deployability — become first-order constraints.

In production HFT, a single core infrastructure repository may contain 26+ million lines of C++ across 100K files, organized into 250+ distinct subprojects: exchange gateways, feed handlers, protocol codecs, shared risk libraries, replay frameworks, and strategy infrastructure. That shared foundation is continuously modified, rebuilt, tested, and deployed by engineering teams across five time zones and more than 40 trading teams, each maintaining their own siloed multi-million-line client systems in C++, Rust, and Python.

Under these conditions, many accepted “best practices” simply do not survive contact with reality. Systems must instead evolve toward what might be called a ground state: components reduced to their essential boundaries and responsibilities, abstract enough to support radically different workloads, but precise enough to compose into a coherent whole.

The challenge is not merely writing fast code. It is building systems that remain correct, flexible, and evolvable while operating under constant latency and operational pressure.

This is not a talk about “perfect architecture,” but about the tradeoffs, hard-earned lessons, constraints, and occasional failures through which generations of engineers — myself included — have kept large systems moving forward without stopping the business behind them.

Last year, the title of this talk would have been "AI in a C++ World." That it isn't anymore tells you most of what changed.

A year ago, AI was the visitor we were evaluating. Now, it is the room we work inside, and the question for C++ programmers is no longer whether to take the technology seriously but how to keep doing serious work in its presence.

Another year of using these tools in earnest on production C++ has clarified what works, and given me an actual workflow to point at instead of a set of slogans.

I'm a professional C++ developer, and yet I haven't written a line of code since last November. Not because I've not written any code, but because AI has written every line.

It is not a theoretical presentation, but a working practitioner's report. I'll walk you through the development workflow I now use for serious C++ development.

Along the way I'll cover what C++ developers actually need to know about how LLMs work, what the agentic loop is, and how to get production-quality C++ out of these systems. The tone is practical, but opinionated, though those opinions are based on personal experience.

If you are not yet using AI as another independent member of your development team, or if you think I'm completely off my rocker, then this talk is definitely for you.

Modern coding agents are incredible, but they still struggle with the kind of large, unstructured codebases that are common in C++. There are several techniques and tools that can make them perform much better. Here we show examples and demos of how to get your agent to work better with complex code. The focus is on providing an overview on current techniques and how we’ve found they work best. - Skills, memory and MCP - these have all been hyped hard, we’ll sort through where they are actually useful. - All agents (Claude, Copilot, Codex, Gemini) support these - some better than others. - What a skill is and what it isn’t - How to use persistent memory - Why MCP servers are still needed (but not always) - Context engineering. - Context management keeps changing - we’ve got autocompaction and 1M token windows now, why should we care anymore? - When to “manage” your agent’s context window and when it’s a bad idea - How to understand where context is being spent. - How and why to use subagents - these are almost always available but the capabilities in different frontends are exposed in different ways. - Spec Oriented Development: buzzword, euphemism for vibe coding or the future of programming? - What is it? - What tools exist? Covering options such as SpecKit, Kiro, etc. - Working in parallel with agent teams! - How to get started without having to learn anything (almost)! - Runtime context. - How to give your agent the best possible feedback path so you can stop micromanaging it and leave it to complete longer, more complex tasks. - Techniques including testing, CI integration and recording-based technology

C++ runs the world’s systems, and with that comes a responsibility for safety and stability. Avoiding AI entirely gives up on incredible potential benefits, but using AI without guardrails poses significant risks to our critical systems. How does AI fit into this world? This talk examines effective and ineffective approaches to using AI in systems that cannot afford “slop.” We will explore several case studies where AI produced significant value in C++, and several where it did not. The pattern that emerges is consistent: AI thrives when it is orchestrating well-defined, deterministic components, translating between them intelligently without being trusted to reason correctly on its own. When AI is asked to be the system rather than connect the system, things fall apart.

Refactoring is defined as "the process of changing a software system in a way that does not alter the external behavior of the code yet improves its internal structure", and is a core skill and process in modern software development. From "cleaning up a little mess" to handling legacy code to improving testability to completely changing architecture, refactoring is the process to achieve that elusive thing, "clean, elegant, and maintainable code".

This talk will cover the basics of Refactoring from three angles. First, we will cover a few of the most important refactoring techniques and connect them to other well-known points of good C++ style.

Second, we'll talk about how to decide what and where to refactor. Common "code smells" are good places to start, but we will also discuss how to look for "seams" along which code can be cut, and how to find hints left in the code by previous developers that can point the way.

Third, we'll discuss how to successfully execute refactoring, even on a busy team and a big code base. What is the "blast radius" of a change, how to minimize the disruption it causes, and how to avoid annoying co-workers in the process.

Have you ever wondered why your C++ class suddenly doubled in size, or why reordering its members made it smaller? This talk introduces memory alignment in C++ from the ground up - what it is, why it is critical, and how compilers handle it under the hood. We’ll start from first principles: how modern CPUs read memory, the difference between aligned and unaligned access, and the performance costs of getting it wrong. Using benchmarks, we’ll see just how impactful misalignment can be. From there, we’ll dive into how compilers lay out data members in structs and classes, and how simple reordering can reduce memory footprint. Live coding examples will illustrate how padding is introduced and how tools like alignas, alignof, and std::align give you precise control. We’ll also look at packed data structures, which trade alignment guarantees for compactness - common in network protocols. While they can save space, they also introduce risks like undefined behavior when misused. Through real-world examples, you'll learn when packed structures make sense, and when they’re a hazard. By the end of the talk, you'll walk away with a solid intuition for alignment and the confidence to manage memory layout effectively in your programs.

std::atomic and std::memory_order are utterly opaque abstractions. It feels like they were put in place to hide some monstrosity that is too complex for mortals to comprehend, and inevitably when trying to understand the underlying reality, the explanations end with 'the processor does weird things' and 'think about it as if...'.

Well, 'think about it as if' no more. In this talk we'll present the gory and wonderful mechanics of cache coherence protocols, store buffers, cache invalidation queues and the in-processor load-store-queue. We'll explain how modern hardware design makes different cores have different views of memory, and what fences and read-modify-write instructions do exactly - for both x86/64 and ARM/RISC-V (which are sometimes dramatically different).

This is an advanced low-level talk located at the borderline of software development and electrical engineering, discussing topics rarely - if ever - discussed at C++ conference talks.

Lightning talks are your five minutes of stardom. The format encourages a focused and often high-energy presentation about nearly anything (subject to approval by the conference) that might be interesting to the C++ community, including proprietary technologies. They can be of a lighter or humorous nature, but they need not be.

Submit your talk here

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

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.

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.

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.

Lightning talks are your five minutes of stardom. The format encourages a focused and often high-energy presentation about nearly anything (subject to approval by the conference) that might be interesting to the C++ community, including proprietary technologies. They can be of a lighter or humorous nature, but they need not be.

Submit your talk here

For a long time, programming was constrained by our ability to produce code. That constraint is eroding rapidly. AI systems can now generate substantial amounts of code with little effort, while inspection, validation, and integration remain difficult.

This transition alters the economics of software engineering. Code is becoming easier to generate than to reason about, and sound judgment grows scarcer relative to specialized intelligence. The emphasis shifts from authoring programs to understanding systems: their structure, invariants, interactions, and long-term evolution.

The talk examines this transition through the lenses of history, language design, and recent developments in AI and metaprogramming. It argues that the central challenges ahead concern not code generation, but the management of complexity at scale.

Topics include: - historical parallels and failed predictions in computing - AI-assisted software development - language design and metaprogramming - C++ reflection and compile-time programming - abstraction as context compression - complexity management in large systems

AI will undoubtedly transform how we build software. As before, the decisive factor will be our capacity to adapt.

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 BonoboMock, a new C++ mocking library we developed and published 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 Bloomberg 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 BonoboMock 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.

Tooling Track sessions are sponsored by Optiver.

First day on a new project. You set up your workstation and then download a repository of over 1,000,000 lines of code. Even more intimidating, the code has been around for 20 years. Parts are in legacy C++, parts use the latest C++26 features, and increasingly, AI coding assistants are weaving new code through all of it, meaning some parts of the codebase may have never been fully understood by a developer. You feel overwhelmed. Don't Panic! In this talk, we share techniques and tools that real engineers use to find their bearings in code they didn't write, from the humble grep through debuggers and profilers to time-travel debugging and AI-assisted exploration. The audience will leave this talk with a mix of simple and advanced tricks for navigating large and complicated codebases.

For decades, lock-free programming has been the go-to optimization for the most contended parts of concurrent programs. The reasoning was simple: locks are slow under contention, so eliminate the locks. This made sense on the hardware of the time, and I should know—I've given several talks explaining how and why to do it. The hardware has changed. Modern CPUs are highly optimized for the operations that make locks fast: cache-line transfers, memory ordering, and speculative execution through lock acquisitions. To set the stage, we will briefly establish why, under high contention, a well-written lock consistently outperforms lock-free atomics and CAS loops. (As an aside, I'll hand you a concrete recipe for a spinlock that actually holds up under extreme contention—and show why systematic backoff, by batching cache-line ownership, is what protects the shared interconnect.) But the core of this talk addresses a completely flipped reality: at low contention, lock-free code decisively outperforms spinlocks, for the most surprising reason. Conventional wisdom assumes an uncontended spinlock is practically free. Using raw hardware performance counters, we will see why it isn't: the implicit synchronization a spinlock imposes—even with no contention at all—is deeply unfavorable to modern out-of-order pipelines, while a single lock-free XADD or CAS, an indivisible read-modify-write, is not. The path everyone assumes is free turns out to be the quietly expensive one. Putting these two facts together—locks winning high contention via cache-line batching, atomics winning low contention by staying out of the pipeline's way—points to a concrete design. I will present a highly optimized MPMC (multi-producer, multi-consumer) queue built on a dual-domain structure that deliberately segregates the contended path from the uncontended one, letting each run on the mechanism the hardware actually favors. We will then walk extensive benchmarks across modern silicon—Intel, ARM server (Graviton/Grace), and Apple (M3)—showing this queue is the fastest, often by wide margins, across most operating regimes. We will also see why the tradeoffs play out so differently per chip, in ways that aren't obvious from the spec sheet, and why "ARM vs x86" is the wrong axis entirely—what matters is the chip's target market, not its instruction set. Finally, no benchmark is complete without honest caveats. I will detail the specific corners where this design can still be beaten, the hidden system costs you pay elsewhere to buy this throughput, and why systems that strictly require progress guarantees—deadlock avoidance, priority inversion, safe execution in a signal handler—mean traditional lock-free programming is not dead. It has simply relocated. If you've ever reached for a complex lock-free algorithm to speed up a highly contended hot path—or wondered what your CPU is actually doing during a mutex unlock—this talk will change your mind about where lock-free programming truly belongs.