CppCon 2026

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.