CppCon 2026

Queues are the backbone of concurrent systems — yet most C++ developers treat them as a black box. Pick the wrong queue topology, misplace an alignas, or use the wrong memory order, and you pay for it in microseconds of latency, invisible cache thrashing, or subtle correctness bugs that only manifest under load. This talk is a rigorous, bottom-up treatment of the four canonical concurrent queue topologies: SPSC, MPSC, SPMC, and MPMC. We start with the hardware reality — how cache coherence protocols turn innocent struct layout into a performance disaster through false sharing — and build upward through the C++ memory model, atomic operations, and queue algorithm design. For each topology, we derive the minimal set of memory ordering guarantees required for correctness, show how to exploit producer/consumer asymmetry to eliminate unnecessary synchronization, and demonstrate how alignas(std::hardware destructive interference size) and deliberate padding can be the difference between 100ns and 10ns throughput. We dissect Dmitry Vyukov's MPMC ring buffer, the intrusive MPSC queue, and Michael-Scott's linked-list queue — not just their interfaces, but the why behind every memory order acquire and every phantom cache line. We then go beyond correctness into the practical engineering tradeoffs: bounded vs unbounded, throughput vs latency, contention vs coordination overhead. Real benchmark data shows how these decisions interact non-obviously — an MPMC queue can outperform MPSC under certain producer counts, and seq cst where you don't need it can quietly halve your throughput. Attendees will leave with a clear mental model for choosing and implementing the right queue for their threading topology, a checklist for false sharing audits, and battle-tested code patterns suitable for low-latency production systems.

Getting a project approved, or killed, often has less to do with technical merit than with who actually holds the keys and what they need to hear. This talk draws on real case studies from library design fights, cross-functional infrastructure rewrites, and a couple of notable failures to show practical techniques: how to find the real decision-maker, how to break expert deadlock with a position paper, and how to build toward an audacious goal through incremental wins and a well timed crisis.

For C++ developers building modular applications or performance-critical loops, modern architecture often forces a painful compromise: you either build heavily decoupled systems that thrash the CPU cache, or you write rigid, tightly coupled code. Distributed builds mask the compile-time symptom — but the underlying coupling bleeds into the runtime hot path.

This talk presents the Capability Routing Grid (CRG), an architecture that refuses this compromise. CRG enables a zero-registry plugin system where modules self-register at link time, and polymorphic dispatch is reduced to an O(1) branchless array lookup — with no central registry, no Init() function, and no runtime search.

Three independent pillars, each usable standalone:

Pillar 1 — Linker-Driven Discovery: Build a fully decoupled plugin system without central registries or Init() boilerplate. Modules self-register via standard C++ static initialization — entirely automatic in monolithic builds, and requiring a single explicit sync-point call at DLL load time.

Pillar 2 — State and Behavior Separation: Enforce a strict architectural boundary between pure data structs and stateless capability objects. This separation — not a framework — is what keeps the hot path flat. Type erasure is available as an optional cold-path utility for cross-boundary routing, but is never required for performance.

Pillar 3 — O(1) Branchless Dispatch: Map multi-dimensional contextual states into a single flat lookup table using basic polynomial math. Because this layout never changes, the CPU branch predictor and hardware prefetcher maintain peak efficiency.

The final payoff: by collapsing capabilities into raw function pointers, the system hits the memory bandwidth ceiling — 33 GiB/s sustained throughput, with a per-dispatch tax of approximately 1.5 nanoseconds.

Data-Oriented Design is defined from scratch. A brief hardware cache primer precedes every performance claim. The entire architecture compiles on C++17 — no language extensions, no experimental flags, on any mainstream toolchain. The audience will leave thinking, "I could have written this" — because they can.

Attendees will learn how to: - Build self-registering plugins with zero shared headers, using standard static initialization across both monolithic and DLL builds - Apply state/behavior separation as an architectural discipline — keeping capabilities stateless and the hot path free of virtual overhead - Replace vtable dispatch with a flat array lookup across N behavioral dimensions — O(1) regardless of dimensionality - Cache resolved logic as raw function pointers and call them directly, reaching memory-bound throughput

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.

Reverse-mode automatic differentiation (AD) computes exact gradients with respect to thousands of inputs in roughly the time of a single function evaluation. If you write numerical C++ for finance, scientific computing, or ML and you care about performance, this talk will show you where AD overhead actually comes from and what to do about it.

A straightforward operator-overloading implementation records every arithmetic operation onto a tape and replays it backward to propagate derivatives. On real numerical code this easily introduces 50-100x overhead, and most of that has nothing to do with calculus. It is heap allocation on every operation. It is cache misses walking the tape backward. It is branch mispredictions at memory chunk boundaries. It is recording tape entries for operations where none of the operands are even being differentiated.

We work through a series of C++ techniques that bring this down to around 4x on production code in finance. The two that matter most: a chunked arena allocator with cache-line alignment and branch-prediction hints that turns the recording hot path into a pointer bump and a store, and expression templates that collapse an entire right-hand side into one tape push with all derivatives accumulated in a compile-time-sized stack buffer. We pull up compiler output to show the abstraction really does compile away.

After the big two, we get into the smaller wins that are still worth knowing about: skipping zero adjoints during the backward sweep to exploit sparsity, picking derivative formulas at compile time that reuse the forward result instead of recomputing it, and demoting active-times-passive operations from binary to unary to halve their tape footprint. We also show how a should-record check propagated through the expression tree lets the tape skip entire statements when no operand is active, and how aggressive inlining lets the compiler eliminate these checks entirely for passive subexpressions, so the cost of asking is zero when the answer is no. We benchmark each one in isolation on four numerical workloads ranging from 8 to 161 sensitivities, so you can see what each technique is actually worth.

Atomic memory ordering is often taught operationally: Use acquire here, release there, and perhaps add a fence “to be safe.” This approach tends to produce cargo-cult synchronization, where atomic operations are selected mechanically without a clear understanding of what information is actually being propagated between threads. In practice, memory ordering is not about memorizing enum values, but about establishing which facts become visible to which observers, and when.

This talk approaches atomic synchronization from first principles. Beginning with the fundamental ideas of publication, visibility, ownership transfer, and synchronization edges, the talk incrementally develops several concurrent structures drawn from real asynchronous systems. Case studies include outstanding-work reference counting, a multi-producer singly-linked publication structure, a concurrently-mutated doubly-linked intrusive list, and the coordination machinery underlying a concurrent operation with multiple concurrent completion modalities. Each structure is used to derive the synchronization requirements imposed by its invariants, rather than selecting memory orderings mechanically.

Along the way, the talk explores the practical meaning of relaxed operations, acquire/release synchronization, and atomic thread fences. Particular attention is paid to understanding what each actually does, when it is necessary, and when it has become a decorative synchronization cargo cult. The goal is not simply to present lock-free algorithms, but to develop a principled way of reasoning about memory visibility and synchronization in real concurrent systems.

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.

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.

Embedded systems often operate under strict timing and reliability constraints, yet most existing file systems prioritize throughput and flexibility over predictability. This mismatch can lead to non-deterministic behavior, unbounded latency, and difficult-to-debug failures in resource-constrained environments. In resource-constrained environments such as automotive control units and aerospace flight systems.

This talk explores the design and implementation of a deterministic file system built specifically for embedded systems using modern C++. Rather than focusing on feature completeness, the system prioritizes predictable behavior through fixed block allocation, metadata-first layouts, and bounded operation times.

We will examine how determinism can be treated as a first-class design constraint, influencing everything from on-disk structure to API design. The talk will also highlight how modern C++ features—such as strong typing, RAII, and compile-time configuration—can be leveraged to enforce correctness and reduce runtime overhead without sacrificing clarity.

Attendees will gain insight into real-world tradeoffs required to achieve determinism, including limitations in flexibility and storage efficiency, as well as strategies for adapting the design across different hardware backends such as file-backed devices, SPI flash, and embedded Linux block devices.

This session is aimed at engineers building systems where predictability matters more than peak performance, and who want to apply modern C++ techniques to low-level, resource-constrained environments.

How far can modern C++ push an emulator before performance stops being a C++ problem and becomes a systems problem? This talk is the final part of a CppCon trilogy about building an extremely fast Game Boy emulator in modern C++, moving from high-performance emulation techniques to the limits imposed by hardware, compilers, and CPU architecture.

The target is intentionally absurd but not arbitrary: a Game Boy emulator running Tetris at roughly 100 times original speed, about 6,000 frames per second. However, the goal is not to support every Game Boy cartridge ever made. This project deliberately specializes for one iconic game first, using the code paths Tetris actually exercises as a guide, while keeping enough design discipline to test other games later. That means questioning the architecture of the emulator itself: instruction dispatch, memory access, generated code size, cache behavior, branch prediction, compile-time computation, benchmarking methodology, and the tension between accuracy, maintainability, flexibility, and raw throughput.

This is not a victory-lap performance talk. It is a measurement-driven engineering investigation. Rather than treating 6,000 FPS as just a headline number, this talk treats it as a stress test: a way to force difficult design decisions into the open. Attendees will leave with concrete lessons about performance-oriented C++: how to measure methodically, how to specialize without losing control, how to reason about modern CPU behavior, and how to decide when an optimization is worth its cost.

Sean Parent's "no raw pointers" guideline is often misunderstood as "avoid T* , use smart pointers instead", even though Sean explicitly included smart pointers in his definition of a raw pointer: "anything with implied ownership and reference semantics".

This talk presents a refinement of that guideline:

Pointers - smart or not - shall not appear in function signatures, neither as argument nor as return type.

The focus of this talk is how to implement classes as regular types while still supporting dynamic allocation, polymorphism, and sharing internally.

It shows how such value types can be implemented manually, without dedicated library support. It then follows the evolution of the language and library in gradually simplifying these abstractions: C++11 smart pointers ( unique_ptr and shared_ptr ), C++26 vocabulary types ( indirect and polymorphic ), as well as in-progress proposals ( copy_on_write and protocol ) are presented as tools to simplify writing safe abstractions, not as safe abstractions themselves.

Along the way, the talk revisits the Rules of 3/5/0, exception safety guidelines, const propagation, aliasing, and local reasoning.

The talk aims to make you stop passing pointers around.

Modern C++ gives developers powerful tools to write cleaner, safer, and more expressive code — but many production codebases still suffer from excessive boilerplate, repetitive patterns, and verbose implementations inherited from older C++ styles.

This talk explores practical modern C++ techniques that significantly reduce lines of code while preserving readability, maintainability, and runtime performance.

Through real-world examples, we will refactor traditional C++ implementations using features such as ranges, structured bindings, constexpr, concepts, CTAD, lambdas, std::optional, std::variant, and std::expected. We will examine where these features genuinely improve code quality — and where they can accidentally hurt clarity or performance if misused.

The session also goes beyond syntax improvements by analyzing generated assembly, compiler optimizations, allocations, and benchmark results to validate whether “shorter” code truly remains zero-cost.

Attendees will leave with practical patterns they can immediately apply to modernize existing codebases, reduce unnecessary complexity, and write more expressive C++ without sacrificing performance.

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.

Teams writing modern C++ libraries with concepts, niebloids, deduction guides, and SFINAE-driven overload sets either accept wrong reference documentation or maintain a Doxygen + XSLT + Sphinx pipeline of workarounds. A different approach is to read C++ from the Clang/LLVM AST, separate corpus extraction from output templates, and recognize common idioms as first-class. This allows the source to stay clean from workarounds.

Doxygen-based pipelines all share these failures on modern C++. Constraint, noexcept, and explicit specifier expressions get truncated or dropped. Niebloids and function objects show as wrappers, not callables. Overloads distinguished by SFINAE or concepts scatter across the output, and CRTP base classes render with the wrong members. All of this disappears when the tool reads the compiler's AST and is able to instantiate specializations.

The talk then covers the architecture of MrDocs, an open-source documentation generator built on Clang/LLVM. Corpus extraction handles the redeclaration, template instantiation, and overload resolution problems that break naive AST traversal. Idiom recognition treats modern patterns as first-class metadata: niebloids, overload sets, concept constraints, requires-clauses preserved verbatim, function-object auto-detection, SFINAE overload sets, and deduction guides. It also captures the specifiers: explicit, noexcept, consteval, storage class, defaulted and deleted functions, and attributes. The templating layer gives full control over the output (HTML, AsciiDoc, Markdown, XML, or custom formats) without forking the tool.

The session is heavy on code from real C++ template libraries, with examples drawn from fmt, nlohmann/json, mp-units, and several Boost and Beman libraries. By the end, you will know why partial AST tools break on modern C++, what an alternative architecture looks like, and which idioms it has to recognize.

C++ journey doesn’t stop at C++20 where people already started to adopt. C++23 is here, it’s maturing, and it’s packed with new features that deserve your attention. In this session, we’ll explore the most practical, accessible, and impactful additions in C++23 features that you can actually start using, not just in toy projects but in real-world code bases.

We’ll compare C++23 to its predecessors, highlight key language and library improvements, and see how these tools can simplify your development, improve readability, and bring more joy to modern C++.

Whether you're already deep in C++20 or still catching up, this talk will help you chart your course into C++23 with confidence and clarity.

Code review is the most consistent contact point most senior C++ engineers have with the developers they are meant to be growing. It is also the place where well-intentioned mentorship most often turns into gatekeeping, bikeshedding, or a queue of unblocked-but-unlearned junior developers. This talk is about treating code review as a deliberate teaching practice rather than a quality gate that happens to have a comment box attached.

We will start by separating the goals of review: catching defects, enforcing conventions, transferring knowledge, and building the reviewee's judgment. These goals often pull in different directions, and most review comments only serve one of them. We will look at concrete review patterns that teach: asking questions instead of issuing edits, leaving the why alongside the what, distinguishing blocking concerns from preferences, and knowing when to pair on a change in person instead of typing a fifth comment thread.

The middle of the talk will work through real examples from reviewing C++ in production: a tricky lifetime bug, a template that needs to become a function, an overload set that quietly broke at a call site, a refactor that touched more than it should have. For each, we will compare the review comment that unblocks the developer with the review comment that teaches them, and discuss the cost of each choice.

We will close with patterns for the reviewer's own growth. How to notice when you are the bottleneck. How to recognize that the same comment is appearing on every PR and what to do about it — documentation, a lunch-and-learn, a refactor, a linter rule. How to make yourself, eventually, less necessary on your own team. Attendees will leave with specific review techniques they can try the next day, and a way to think about review as a long-running mentorship relationship instead of a per-PR transaction.

Modern hardware is increasingly complex and difficult to reason about; effective C++ performance work therefore demands a disciplined loop - profile, benchmark, analyze. Yet profiling alone is tricky, doesn’t answer “what if” questions, and manual benchmarking is dominated by hidden biases.

This talk presents a novel automatic benchmarking approach that focuses on eliminating measurement biases. We combine symbolic execution of identified hot regions with microarchitectural state randomization to systematically explore latency and throughput behavior under diverse - cache, branch, data layout - conditions. The technique is integrated with Linux perf, so the entire process - region isolation, state variation, measurement, analysis - is fully automatic.

The talk first grounds attendees in profiling with hardware performance counters, Top‑down Microarchitecture Analysis (TMA), and processor tracing. We then demonstrate how to automatically stress specific microarchitectural features to produce statistically reliable, "bias‑free" benchmarks. Finally, we close the loop with machine‑code analysis, showing how the measured numbers connect directly to instruction‑level behavior and ultimately to C++ code.

Attendees will leave with a concrete framework they can apply immediately to better understand and improve C++ performance.

The White House says stop using C++. CISA wants a memory safety roadmap. The internet says rewrite everything in Rust. Meanwhile, embedded teams are shipping firmware on Cortex-M microcontrollers with limited flash, no MMU, no virtual memory, and a codebase that cannot be rewritten overnight. So what do you actually do?

This talk is a practical, tool-by-tool walkthrough of every memory safety technique available to embedded C++ developers right now — and what is coming in C++26. It starts with what you can turn on today without changing a single line of code: compiler warnings that most projects still ignore, AddressSanitizer and UndefinedBehaviorSanitizer running on host-compiled firmware, and stack protection options that cost single-digit bytes of overhead. It then moves to code-level improvements that modern C++ makes possible: replacing raw pointer arithmetic with std::span, using std::expected instead of error codes that nobody checks, applying constexpr to move validation to compile time, and adopting strongly typed wrappers to eliminate unit-of-measure bugs. Finally, it covers what C++26 brings to the table — hardened standard library containers with bounds checking at 0.3% overhead, safety profiles for type and bounds and lifetime checking, contracts for defensive preconditions, and the elimination of uninitialized-variable undefined behavior — and evaluates which of these features are realistic for embedded targets today.

Every technique is evaluated on three axes: how much code do you have to change, what does it cost in code size and runtime on a real microcontroller, and what class of bugs does it actually prevent. Attendees will leave with a prioritized adoption checklist they can bring back to their team on Monday.

Most C++ programmers are familiar with the traditional C++ facilities for text processing found in the iostream and string libraries. However, std::format (C++20) and std::print (C++23) provide new text formatting tools that are unfamiliar to many C++ programmers. While these new facilities can be very helpful, they can also produce some very intimidating error messages when misused. Moreover, the process for writing your own user-defined types that you can format with std::format and std::print is not very straightforward.

This session starts with an overview of the traditional C and C++ text processing libraries. It then shows how std::format and std::print neatly combine benefits from both the C and C++ libraries to create a safer, more convenient interface. After that, this session explains the steps you must take to write user-defined types that work cleanly with std::format and std::print. You’ll leave this session with a clearer understanding of the benefits of using these new text formatting facilities and how to integrate them into your existing code base.

const is one of the oldest and most widely used features in C++, yet many developers still struggle with the subtle differences between const , constant expressions, constexpr , and consteval .

In this talk, you will learn how compile-time constants evolved in modern C++, starting with const and continuing through the features introduced since C++11. You will see what constant evaluation really means, what the compiler is allowed to execute during compilation, and where the limits still are today.

Using practical examples, we will explore when const is enough, when constexpr is needed, and how compile-time and runtime execution interact in modern C++. We will also look at common pitfalls, surprising behavior, and cases where compile-time programming can either improve code or make it harder to understand.

Finally, you will see how features such as consteval and std::is_constant_evaluated influence correctness, testing, and maintainability.

By the end of this talk, you will have a deeper understanding of constant evaluation and know how to use modern compile-time features more effectively in your code.