CppCon 2026

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

Application developers sometimes hit a limitation of a 3rd-party library or framework. The Type Erasure design pattern can help us overcome such limitations without the need to change the 3rd-party API.

Type Erasure is a relatively complex design pattern that allows us to treat a set of unrelated classes as if they shared a common base class, while preserving value semantics. The downside is increased code bloat and code complexity as the pattern requires a significant amount of additional code.

There have been quite a few talks explaining HOW to implement Type Erasure, while the topic of WHEN has been rarely discussed. Should we always use type erasure instead of virtual polymorphism? And if not, then what are the criteria?

This talk will show a concrete example from the audio programming industry of how Type Erasure allowed adding new functionalities to the parameter class system of the JUCE C++ framework without changing its API. As such, the talk will be useful for application and library developers who use 3rd party libraries but need an extra degree of flexibility.

You will come out of the talk understanding

• what Type Erasure is,
• when to use it, and
• how to implement it.

You don't need to understand Type Erasure, audio development, or JUCE to attend the talk; the necessary minimum will be explained during the talk.

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.

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.

Native C++ types often become the format for bytes that cross a boundary: shared-memory IPC, plugin interfaces, persistent storage, or software built for more than one ABI. At that point the type is no longer just an implementation detail; it is part of a binary contract. trivially_copyable , sizeof , and code review help, but they do not answer the two questions that matter: may this type be transported as bytes at all, and do all supported ABIs give it the same object representation?

C++26 reflection can derive that evidence from the type itself. The technique builds a compile-time layout signature from ordinary C++ types, without IDL, generated stubs, or runtime inspection. The signature records the representation facts needed for byte transfer: architecture and endianness, leaf type tokens, sizes, alignments, absolute offsets, bit-fields, and pointer-like markers. It deliberately leaves out field names and source-level meaning.

With those signatures in hand, the build can enforce a gate for memcpy-style transfer. You name the boundary types and supported ABIs. Each target exports signatures, and a verification build permits direct byte transfer only when the type is byte-copy safe and the signature matches across the set. We'll walk through the workflow with static_assert checks and CI diagnostics: a fixed-width type that passes, a pointer-containing type rejected by admission, and a platform-divergent type rejected by signature comparison. The claim is intentionally narrow: representation compatibility, not semantic compatibility or schema evolution.

Practical HPC — Forcing the Compiler's Hand with Modern C++

Achieving near-peak FLOPs on modern CPUs requires exploiting SIMD, register files, and cache hierarchies — yet the levers that matter most (loop unrolling, vectorization width, tile sizes, register tiling) are largely outside the programmer's direct control. Autovectorization is fragile, #pragma unroll is advisory and non-portable, and the information the compiler needs most — loop bounds, problem shapes, working-set sizes — is typically only available at runtime. The result is a familiar gap between theoretical peak and delivered performance, bridged in practice only by hand-written intrinsics or inline assembly, fragile macro forests, or external code generators that sacrifice maintainability and type safety.

Modern C++ is, sometimes surprisingly, an excellent language for closing that gap without leaving the host language. We walk through the concrete features that make this possible and how to use them in practice — templates and constexpr to promote runtime values into compile-time constants, if constexpr and parameter packs for shape-specialized kernels, generic and template lambdas for loop bodies that are unrolled and inlined by construction, and concepts to turn silent performance cliffs into compile-time errors. Together, these give the programmer precise control over what the compiler emits: compile-time dispatch that specializes kernels per shape and target, guaranteed static unrolling that unlocks ILP and register tiling without relying on optimizer heuristics, and hardware-aware specialization parameterized on register count, SIMD width, and cache sizes.

Looking forward, C++26 and static reflection push this approach considerably further, turning today's disciplined metaprogramming into something closer to first-class, in-language code generation — and squarely aligning the language with the goal of making inline assembly unnecessary, even at the highest performance tiers.

These patterns are powerful but verbose and reappear across kernels, so we briefly introduce POET (Performance Optimized Excessive Templates), a header-only library usable from C++17 onward that packages the most common cases as ready-to-use building blocks, alongside xsimd for portable SIMD.

As a concrete case study, we walk through a real scientific-computing kernel — a workload of the kind that has historically demanded hand-tuned assembly — and show how these abstractions get within a small fraction of theoretical peak throughput while keeping the source readable, portable, and maintainable, with no inline assembly, no compiler builtins, and no external code-generation step. Scientific computing does not have to choose between performance and engineering quality, and with the right abstractions, development becomes dramatically more effective.

How far can C++26 reflection take us? What are some techniques, gotchas, limitations and workarounds? How would reflection help write code that interacts with bespoke binary data formats? Come along as we explore a practical example together.

This talk will review advice gleaned from applying C++26 reflection to binary (structs on a wire) protocol handling. This type of protocol exists all around the world from financial market data formats to custom hardware interaction. Is the proposed reflection support enough to take a protocol definition written in the native terms of C++ and create flexible components to interact with that protocol?

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.

Scripting in a C++ game engine should not cost you the engine's native performance. This talk shows how C++26 static reflection and std::meta::substitute in particular can lift a scripting language's bytecode into C++ template structures that the compiler optimizes away entirely, collapsing the interpreter dispatch loop into the same machine code you'd write by hand. Scripting languages like AngelScript and Lua are invaluable in C++ engines: they give designers a fast iteration loop without rebuilding the engine. But they come with a paradox. The engine you chose for raw performance now spends cycles on every frame interpreting a slower language, juggling a software stack and checking types at runtime. We will walk through the technique step by step, starting from a plain bytecode interpreter and ending at a fully reflected program where a scripted sum(0..10) compiles to mov eax, 45; ret. Along the way you'll learn the core C++26 reflection primitives (^^, [: :], std::meta::substitute), how to assemble bytecode into structural templates like block<> and loop<>, and how these techniques generalize to embedding any stack or register based scripting language in your engine with zero runtime overhead.

In C++, monadic operations are a commonly utilized API for interacting with result types like std::optional and std::expected. By chaining the computations, these abstractions allow you to manipulate the underlying values using less boilerplate code. Monadic operations are a powerful tool suitable for a variety of usage scenarios. They enhance code robustness and significantly lower the risk of accidental errors.

Despite its benefits, many users consider the syntax of monadic operations to be overly verbose, and the underlying concept often seems complicated. There are also the cases where the restrictions placed on functions require using extra statements, specific return and arguments types, and reduce code readability. However, are there other options available? Do we have promising alternatives? The short answer is: yes. While C++ does not yet include pattern matching as a native language feature, the standard library still offers tools for achieving many useful pattern-matching-like functionalities. We will explore how to apply std::visit to this problem and evaluate if an abstraction, which we might call std::match, could serve as an effective substitute for monadic operations in various situations.

Based on several years of practical production experience, this talk will explore the use of monadic result type interfaces and comparable alternatives. This information will benefit practicing software engineers looking to deepen their understanding of these features and integrate them into their codebases.

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++20 modules are finally usable end to end, from your own modules to 'import std;' The functional build-system support with real diagnostics. This talk teaches modules the way #include was once taught: with small files, a build, and concrete use cases. Modules stopped being experimental somewhere around 2025. This session builds the mental model from scratch: what a primary module interface unit is, how partitions and implementation units fit together, and, crucially, how import differs from #include in ways that matter day to day. It uses a small library, exposes it as a module, splits it across partitions, consumes import std; and observes the compile-time effect. Then it answers the questions every team hits in week one: how modules interact with macros, with templates in headers, with header-only dependencies, and with a mixed codebase that can't convert everything at once. The examples will be using CMake, clang and recent gcc. You will leave able to structure a small library as a module, explain why a macro didn't cross a module boundary, and plan an incremental adoption that doesn't require converting the whole tree.

C++ lifetime management is fundamentally built around synchronous scope exit. Constructors establish invariants, destructors release resources, and RAII permits ownership and cleanup to compose naturally with ordinary control flow. Asynchronous systems disrupt this model. Destruction may itself require asynchronous work, and “just launch another task in the destructor” quickly turns deterministic lifetime management into unstructured background activity.

This talk explores the implementation of async lifetime management in std::execution, based on the enter/exit scope sender framework proposed in P3955. Rather than treating async construction and destruction as special cases, the model reframes them as composable asynchronous protocols built around explicit async scope entry and exit operations. The talk follows the process of turning these ideas into working code, beginning from the low-level enter/exit sender abstractions and progressively assembling higher-level lifetime facilities on top. Along the way, the implementation uncovers an important self-similarity in the problem domain: Higher-level async lifetime facilities can themselves be expressed in terms of the same lower-level async lifetime primitives.

The implementation discussion focuses on the machinery required to make these guarantees real: Coordinating async teardown within structured concurrency, managing partially-entered scopes, and preserving deterministic cleanup semantics even when destruction itself becomes asynchronous. The resulting design serves both as a practical exploration of async lifetime management and as a case study in how implementing an abstraction can reveal deeper structural properties hiding inside the model itself.

The software in most embedded projects written in 2026 looks like the software in embedded projects written in 1996. This isn't because 1996 was the peak of innovation and quality but rather has more to do with biases and FUD. Unfortunately, much of the world suffers from these choices: users, developers, managers, and shareholders.

There are better ways to write firmware for embedded systems; proven techniques and implementation strategies that I will describe in this talk. We will explore techniques based on abstraction and composition that maximize understanding while reducing the codegen footprint. We will apply these strategies at all levels of the firmware stack: interrupts, register manipulation, peripheral communications, and the application glue.

Join me and leave with open-source libraries, an open-source starter project, and techniques that you can apply to your greenfield and existing projects.