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.

Some of the most expensive C++ bugs are not caused by obscure language features. Instead, they emerge from code that looks reasonable: shared ownership that quietly extends lifetimes, singletons that become invisible dependencies, and performance-driven decisions that harden into architecture.

This talk examines these common design-level failure patterns in large-scale C++ systems. We cover three concrete design shifts:

Lifetimes: Shifting from shared ownership to explicit lifetime boundaries. Coupling: Shifting from implicit global coupling to injected dependencies. Interfaces: Replacing permissive APIs with constrained interfaces using std::span, std::optional, std::variant, and strong types.

Each shift is presented with the failure pattern it addresses, the solution, and the design rule it yields. Attendees will leave with practical heuristics for designing systems that are easier to reason about, test, and evolve: all grounded in real-world failures and the redesigns that fixed them.

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.