CppCon 2026

std::atomic and std::memory_order are utterly opaque abstractions. It feels like they were put in place to hide some monstrosity that is too complex for mortals to comprehend, and inevitably when trying to understand the underlying reality, the explanations end with 'the processor does weird things' and 'think about it as if...'.

Well, 'think about it as if' no more. In this talk we'll present the gory and wonderful mechanics of cache coherence protocols, store buffers, cache invalidation queues and the in-processor load-store-queue. We'll explain how modern hardware design makes different cores have different views of memory, and what fences and read-modify-write instructions do exactly - for both x86/64 and ARM/RISC-V (which are sometimes dramatically different).

This is an advanced low-level talk located at the borderline of software development and electrical engineering, discussing topics rarely - if ever - discussed at C++ conference talks.

Compiler Explorer looks simple: type code, get assembly. Underneath: a fleet of sandboxed machines running hundreds of compilers across dozens of languages, terabytes of binaries to keep current, and the ongoing problem of executing arbitrary code from internet strangers.

A lot has changed in the 14 years that the site has been around: The sandboxing layers that let it run other people's code without losing sleep. The storage situation that very nearly broke it, and the content-addressable filesystem that quietly rescued everything. The operational war stories, the migration sagas, and the bits that are far more boring than they look from the outside. Along the way you'll see some of CE's recent features in their natural habitat, and get a peek at what's coming next.

You'll come away with a working mental model of how to run untrusted compilation at scale - and why the parts that look easy are almost always the hard ones.

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.