CppCon 2026

This talk presents some design choices, compromises, and optimisations of the implementations of std::flat map and std::flat set. It will cover a brief design history of the original paper regarding the class layout, libc++'s best effort to provide strong exception guarantee on those containers, compromise on the iterator choices between SCARY and more strongly typed, some optimisations on various operations and some tips about avoiding running some issues with these containers.

Large-scale robotics organizations operate diverse fleets of manipulators — 4-DOF arms on rails, 6-DOF standard manipulators on pedestals and fully mobile manipulators — each with different kinematics, hardware vendors, and software teams and researchers.

And engineers and researchers are opinionated.

As a team eventually you have one goal. Re-use as many abstractions; ideas and algorithms as you can while still allowing you the flexibility to explore new algorithms; ideas and approaches.

This talk presents a layered C++ architecture that solves this at scale. We present our core abstrcactions; a header-only Lie group library provides shared spatial math types (SE(3) poses, twists, wrenches); a trajectory library for motion planners and controllers; and a collision detection library from the same.

We will discuss how we moved from virtual functions to C++ concepts with zero overhead and the learnings along the way that allow us to write planning and control algorithms for various robots morphologies and sensing paradigms.

Critically, this architecture balances the needs of production at scale while enabling experimentation: researchers can prototype new collision algorithms, try a new physics engine, or test a novel trajectory representation — all without disrupting production code. The backend boundaries are where new ideas enter the system. You'll leave with three distinct C++ patterns for backend abstraction — compile-time traits, runtime interfaces, and type erasure — and an understanding of when to use each based on performance requirements and the need for experimentation.

Modern storage hardware has evolved at a breakneck pace. PCIe Gen 5 NVMe drives can push data at 10 GB/s, yet standard C++ file abstractions often leave them starving for data. Many developers think they need to abandon portability in favor of unmaintainable, OS-specific kernel bypasses to achieve the throughput necessary to saturate these drives. This session is for developers writing high-throughput, performance-critical applications who want to hit bare-metal speeds without sacrificing clean architecture, cross-platform support, or type safety.

Using a high-throughput cryptographic hashing engine as a concrete case study, this presentation demonstrates how to design a hardware-saturating data pipeline built entirely on the idioms of C++26. We will explore how the mathematical design of an algorithm - specifically BLAKE3's binary Merkle tree structure - can be mapped directly to wide SIMD vector lanes and concurrent CPU cores. We will walk through an execution model that completely bypasses the OS page cache, orchestrates memory without heap allocations on the hot path, and unifies OS kernel quirks in a portable way.

By the end of this presentation, you will learn how to replace rigid thread pools with lock-free, asynchronous execution graphs using Sender/Receiver paradigms (std::execution) and vectorization (std::simd). Crucially, we will focus on the build engineering required to make this work today. We will cover how to use advanced CMake tooling to safely compile multi-architecture vector binaries from a single source of truth, how to prevent LTO cross-contamination, and how to structure your pipeline today to seamlessly absorb upcoming C++ features in a world of trailing vendor toolchains.

As of C++11 there are 6 special member functions that the compiler will generate for us if we don't do anything to get in the way.

But there are many other member functions, in the form of comparison operators, that we can =default explicitly

Which of these should we =default? How do we help the compiler, or stay out of its way?

How many do we need to implement? When can you trust the compiler or not?A

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.

In this talk we will explore "Concepts," a powerful feature for expressing template requirements added in C++20. Participants will learn how concepts improve code readability, provide clearer compiler diagnostics, and help enforce correct usage of templates and function overloading. Through simple, hands-on examples, we will explore the syntax, common use cases, and best practices for integrating concepts into modern C++ code. By the end of the session, attendees will understand how to write safer, more maintainable template code and leverage concepts to communicate intent clearly.

This session dives deep into the world of vulnerabilities from a C++ developer's perspective. Using a simple embedded device as the playground, where the memory model is stripped to the bare essentials, attendees will explore how classic attacks like buffer overflows can be used to hijack control flow, inject code, and manipulate the stack.

Everyone has heard the warnings about buffer overflows, use-after-free, memory corruption, and other infamous vulnerabilities lurking in low-level code. But many developers accept that these traps should be avoided without truly understanding how the exploits work. In this talk, attendees will see hands-on examples of how memory vulnerabilities arise, how they’re exploited, and why they’re dangerous.

But this session is not just about breaking things, it is about building them right. We will explore how modern C++ techniques like smart pointers, bounded containers, and RAII can prevent these issues altogether. By the end of the talk, developers will not only understand the risks but feel confident applying C++ best practices to write safer, more robust code.

Whether you are a systems programmer, embedded developer, or security-minded engineer, this session will deepen your understanding of C++, not just as a powerful language, but as a tool for writing secure, reliable software.

Applications that present rapidly changing market data to human users face a practical challenge: updates may arrive thousands of times per second, but humans only benefit from periodic refreshes. Efficiently coalescing and scheduling that work without overwhelming CPU resources becomes a concurrency problem rather than simply a rendering problem.

This talk demonstrates how modern C++ atomics can be used to build a lock-free timer scheduler optimized for extremely high update rates. The scheduler follows a single-producer, multiple-consumer design in which work items represent recurring tasks that must execute periodically. Consumers process scheduled work and re-schedule it for future execution without relying on traditional locks or centralized coordination.

The most unusual aspect of the design is its “reverse work stealing” behavior: consumers can proactively give away work to other consumers and become idle themselves. Rather than distributing work evenly across all threads, the scheduler attempts to pack work onto as few cores as possible, reducing idle spinning, lowering CPU utilization, and improving cache locality. Because tasks may have highly variable execution times, the scheduler must also prevent pathological cases where work is endlessly redistributed between consumers.

Attendees will learn how atomics, lock-free forward lists, and memory ordering can be combined to implement high-throughput schedulers with predictable latency characteristics. The talk also discusses practical tradeoffs, implementation challenges, and performance measurements from production-inspired workloads, including producer throughput of approximately 50 million scheduled tasks per second and consumer processing throughput approaching 700 million tasks per second, while keeping migrated work items below 1% in typical workloads.

Your system has interchangeable strategies chosen at runtime, but the hot path runs millions of times per second. Runtime polymorphism has virtual dispatch overhead. Templates give you performance but lock you at compile time.

This workshop shows how to leverage inheritance for extensibility while avoiding vtable overhead, using a layered architecture of compile-time patterns. We'll build them up through OpenJDK's GC barrier system, where different GC algorithms compose different barriers on one of the hottest paths in the JVM.

We will also discuss trade-offs against alternatives like std::variant, function pointers, and plain virtual dispatch throughout. No JVM knowledge required.

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.

Many of the problems you encounter in C++ have already been solved, just not by anyone you talk to regularly. Idioms encode best practices into recognizable patterns that help reduce cognitive load, convey intent, and eliminate entire categories of bugs. However, C++ isn’t a single community. It is a language spoken across many industries, including, but not limited to: scientific computing, games, embedded systems, and finance. Each of these domains has developed its own idioms, patterns that are shaped by the specific constraints they face.

While our vernacular evolves independently, the problems they solve often overlap. Consider the convergence around the Curiously Recurring Template Pattern (CRTP) and variant-based dispatch. Embedded systems engineers, working without a heap, paired CRTP with tagged unions to achieve polymorphic behavior over a closed set of types in static storage. Independent of this, high frequency trading firms, driven by latency rather than memory constraints, adopted the same combination to avoid indirect branches and allocator contention. Two communities, two different constraints, but the same pattern. Unfortunately, since each community was solving the problem in isolation, it had to be discovered twice.

This is not a new phenomenon. C++ idioms have been crossing boundaries since at least Coplien’s 1992 work on advanced programming styles. Data-oriented design is making a similar journey today, moving from game engines, where cache-friendly layouts are basically required, to financial systems, where the same CPU architecture imposes the same penalties.

Like a spoken language, C++ evolves not just through formal specification but through usage. New idioms emerge as communities discover better ways to express intent with new or existing features. They grow and spread via conferences, open source libraries, and cross-industry hiring. The C++ Core Guidelines capture some of this evolution, but much of it lives within codebases and communities that you may never find if you don’t look.

This is a call to look for them. We will trace how specific idioms have traveled between industries, examine what made them transferable, and argue that the next improvement to your codebase may already exist, written in a usage of C++ you haven’t learned about yet. While you are at this conference, attend the talks from industries other than your own. You may find a solution in a session that you may otherwise skip.

Last year I introduced the SDL3 library which provides a solution for building games and graphical applications on multiple platforms. In this talk, we will continue our journey into SDL3, which newly includes the ability to write shaders within the built-in 2D API. My goal is to get you up and running fast by building out a small game application. Throughout the talk I will show how to build a small 2D framework, discussing design decisions and which C++ features can be used to help organize our code. Attendees will leave this talk ready to build multimedia / game applications and with an understanding on if SDL3 is the right tool for them.