CppCon 2026

What does it take to build a real-time embedded control system in modern C++, simulate its environment, command it from a browser, and watch it fly in 3D — all from the same open source ecosystem? This talk follows that pipeline end-to-end: from a C++23 real-time framework that schedules deterministic control loops across POSIX hosts and bare-metal microcontrollers, to GPU-accelerated simulation with CUDA, to web-based operations and telemetry, to live 3D visualization in Unreal Engine.

Attendees will see how a unified runtime architecture can span embedded control, simulation, diagnostics, operations, and visualization without fragmenting into separate software stacks. The talk explores deterministic scheduling, zero-allocation real-time design, cross-platform deployment, and integrating CUDA compute kernels directly into scheduled control loops without blocking execution. It also covers tooling for validating deterministic real-time behavior, along with techniques for streaming telemetry and sensor data between simulation and visualization layers in real time.

The presentation includes live demonstrations of a quadcopter simulation flying a programmed trajectory with lidar feedback, and a full-fidelity aircraft simulation with closed-loop autopilot, engine dynamics, and atmospheric turbulence — both running through the same real-time framework and rendered live in Unreal Engine. Whether you build flight software, robotics systems, industrial controllers, or simulation infrastructure, this talk presents practical architectural patterns for modern real-time systems in C++ that bridge embedded devices, GPU compute, and interactive visualization.

Developers of large C and C++ projects have to choose between two main development paradigms: component based development and monolith based development, each one with its own advantages and disadvantages.

In component based development, projects can be split in multiple repositories that allow to do decouple development and releasing, which suits well for many organizations that split the work in different teams with different development speeds. But this approach requires efficient dependency management, complicates working simultaneously in multiple components and it adds extra challenges to implement Continuous Integration at scale.

On the other hand, in monolithic/monorepo base development, the build system tool manages the whole project efficiently, simplifying some development and integration flows. But it can be resource-intensive on the CI side and it also push the whole organization to move at the same speed, often with little or almost no versioning: the “live at head” paradigm

It is said that by Conway's law, organizations are forced in practice to choose between them. But what if modern C and C++ tooling allowed us to have the best of both worlds?

This talk will present the novel Conan2 “Workspaces”, a monolithic view of multiple independent components that can be dynamically added and removed from the monolithic build, and how leveraging CMake FetchContent, such a single monolithic build can be implemented.

Also, for the cases where not only CMake is involved, a quick overview of the orchestration of workspace incremental builds for heterogenous build systems and CI at scale will also be introduced.

The talk will describe the basics, tools, design and architecture of the solutions, and it will also show full working demonstrations for them.

Building on the recent work of improving the quality of Sea of Thieves' codebase by upgrading from C++14 to C++20, this talk will focus on the work that has went into enabling warnings as errors on the game, and more.

Rare will discuss the motivations behind wanting to crank up the warning level, and to flick the "warnings as errors" switch after 10 years of development in their multi-million line Unreal Engine code base.

What were the challenges? How much effort did it take? Was it worth it? Did we find any bugs? Did we stop at just "/W4 /WX"? What warnings did we find the most useful? What warnings were deemed unhelpful? All of these questions and probably more will be answered throughout this session.

Modern coding agents are incredible, but they still struggle with the kind of large, unstructured codebases that are common in C++. There are several techniques and tools that can make them perform much better. Here we show examples and demos of how to get your agent to work better with complex code. The focus is on providing an overview on current techniques and how we’ve found they work best. - Skills, memory and MCP - these have all been hyped hard, we’ll sort through where they are actually useful. - All agents (Claude, Copilot, Codex, Gemini) support these - some better than others. - What a skill is and what it isn’t - How to use persistent memory - Why MCP servers are still needed (but not always) - Context engineering. - Context management keeps changing - we’ve got autocompaction and 1M token windows now, why should we care anymore? - When to “manage” your agent’s context window and when it’s a bad idea - How to understand where context is being spent. - How and why to use subagents - these are almost always available but the capabilities in different frontends are exposed in different ways. - Spec Oriented Development: buzzword, euphemism for vibe coding or the future of programming? - What is it? - What tools exist? Covering options such as SpecKit, Kiro, etc. - Working in parallel with agent teams! - How to get started without having to learn anything (almost)! - Runtime context. - How to give your agent the best possible feedback path so you can stop micromanaging it and leave it to complete longer, more complex tasks. - Techniques including testing, CI integration and recording-based technology

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.

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

Last year, the title of this talk would have been "AI in a C++ World." That it isn't anymore tells you most of what changed.

A year ago, AI was the visitor we were evaluating. Now, it is the room we work inside, and the question for C++ programmers is no longer whether to take the technology seriously but how to keep doing serious work in its presence.

Another year of using these tools in earnest on production C++ has clarified what works, and given me an actual workflow to point at instead of a set of slogans.

I'm a professional C++ developer, and yet I haven't written a line of code since last November. Not because I've not written any code, but because AI has written every line.

It is not a theoretical presentation, but a working practitioner's report. I'll walk you through the development workflow I now use for serious C++ development.

Along the way I'll cover what C++ developers actually need to know about how LLMs work, what the agentic loop is, and how to get production-quality C++ out of these systems. The tone is practical, but opinionated, though those opinions are based on personal experience.

If you are not yet using AI as another independent member of your development team, or if you think I'm completely off my rocker, then this talk is definitely for you.

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?

This talk is the 2026 edition of our series that highlights low-latency, networking, parallelism, and concurrency proposals to the C++ Standards Committee, especially those discussed in the Kona 2025, Croydon 2026, and Brno 2026 meetings. This talk from the Concurrency TS2 Editors, DG and SG14/19 chair will describe the following features and show how they can be used. It will also give their motivation, background, and their place within the overall framework of C++ low latency, networking, parallelism and concurrency:

Atomic Compare and Hazard Pointers Reclamation Control

• We discuss a proposal for atomic compare operations that clarify programmer intent and simplify static analysis by avoiding the unnecessary leakage of atomic values. We also explore how these operations complement recent proposals to enhance the expressiveness of atomics, such as the use of tagged pointers.
• We examine techniques for controlling C++26 hazard pointer reclamation, demonstrating how to offload retirement overhead to asynchronous executors to ensure predictable thread latency. We show how this capability can prevent specific deadlock scenarios and assess whether such controllers should be standardized or remain user-space patterns.

Twenty-One Years Without Sockets, The History of Networking in C++ and What We Learned Along the Way

• Go has standard networking. Rust has standard networking. C++ has been trying since 2005. This talk tells the twenty-one-year story in seventeen minutes: the library that shipped but never standardized, the dependency that blocked it, the coroutine revolution that changed the assumptions, the technical discovery that explains why I/O doesn‚Äôt fit the three-channel model cleanly, and the bridge that lets both models win. Three decision points, three lessons, one live question: how should coroutines and senders coexist for C++29? No villains. Just the story and the engineering. Networking is now finally a C++29 priority, so said the Direction Group‚Äôs P5000.

Out-of-Thin-Air (OOTA) Values.

• The memory models for high-level languages, including C++, C, Rust, and even Java, have been prone to out-of-thin-air values. For example, given two atomic integers X and Y, both initially zero, if one thread does a relaxed assignment from X to Y and the other does a relaxed assignment from Y to X, the mathematical C++ memory model does not rule out the outcome where both X and Y have the value 42. However, both communication and computation take time, and so we have proven that OOTA values cannot happen on real-world production-quality computer systems. This result makes compiler-writers‚Äô lives easier, and also eases the jobs of those brave individuals pursuing the full mathematical OOTA problem by relieving them of the need to live within CPU and memory constraints of production-quality compilers.

Discussion

There are other features under discussion, but the features we will present seem close to approval, are particularly interesting, and/or are relatively non-controversial. We will show use cases for each and prognosticate their journeys to C++26 and beyond. This will help programmers in concurrency, lock-free programming, and low-latency applications understand how best to take advantage of each of these important facilities.

Starting from the simple objective of writing an optimized lexer we will grapple with their fundamental performance factor: branch prediction. We will investigate how lookup tables can improve (or hurt) the CPUs prediction capabilities with some unexpected results. Over time our design evolves by combining parsing and lexing into a single step in a way that is as fast as just a standalone lexer. A central aspect of the design will be a primitive parsing state machine from which the parser source code is generated.

After the talk attendees will have a better understanding of some advanced branch prediction techniques and should have some new ideas for their present or future parsing endeavors.

Modern C++ development involves much more than compiling source files. Cross-platform builds, dependency management, C++ modules, package metadata, SBOM generation, CI infrastructure, and distributed builds have all increased the complexity of software engineering over the last two decades.

CMake has evolved alongside those challenges.

This talk explores how modern CMake helps make difficult software-engineering problems more manageable through targets, dependency modeling, metadata generation, debugging tools, and scalable build orchestration.

We will examine how CMake supports C++20 modules, including dynamic dependency scanning, build graph updates, and import std.

We will also look at CPS and SBOM generation together: CPS provides machine-readable package metadata, while SBOM support helps CMake expose software supply-chain information from the dependency graph.

Next, we will discuss debugging CMake itself using the CMake debugger protocol, and debugging builds using the CMake Instrumentation API to understand where time is spent during configuration and build execution.

Finally, we will examine distributed execution and build acceleration, exploring options available to CMake users in both open-source and commercial environments.

Along the way, we will discuss the real-world challenges, trade-offs, and lessons learned from evolving a long-lived build system to meet the demands of modern C++ development.

This is not your mother’s CMake.

In low-latency C++, correctness is table stakes. What separates good systems from great ones is predictability — the ability to hit your deadline not just on average, but at the 99th and 99.9th percentile, where real workloads live. Latency is a feature, and if you don't design for it explicitly, you lose it accidentally.

This talk is a practitioner's guide to writing C++ that behaves predictably under load, drawn from experience building and tuning low-latency systems on Microsoft's Azure Core platform. We start from the mental models that matter most — CPU-centric thinking, the latency stack from L1 to DRAM, and why minimizing work, unpredictability, and memory movement is the foundation of everything else — and then work through the layers of the stack where latency is won or lost in practice.

Through live demos and benchmark data on both x86 and ARM, we'll cover:

STL containers as latency contracts — why most latency bugs start with the wrong container, the real cost of dynamic reallocation, and the measurable wins from reserve() and custom allocators.

Memory layout and cache behavior — struct layout and alignment (and how it differs on x86-64 vs. ARM64), AoS vs. SoA trade-offs, hot/cold data separation, false sharing, NUMA, and TLB pressure.

Atomics vs. mutexes — when atomics actually lose to mutexes, why architecture and memory model dictate the answer, and how to choose between them in real code.

Threading and scheduling — fixed vs. dynamic thread pools, context-switch and migration costs, and why understanding the OS is half the battle.

Benchmarking and observability — why microbenchmarks lie, how to avoid measurement bias and jitter, why latency histograms beat averages, and why "absolute benchmark" is a myth.

You'll leave with a practical playbook for designing and measuring low-latency C++ systems, an honest understanding of why benchmarks from one machine rarely generalize to another, and a sharper instinct for the silent killers — allocations, branches, cache misses, and synchronization primitives — that don't show up in code review but do show up in production.

Zero-cost abstractions are a foundational idea in C++, promising expressive, high-level code without sacrificing performance. However, developers often encounter unexpected costs when using modern abstractions in practice, even when the code appears idiomatic and well-designed.

This talk explores the assumptions behind zero-cost abstractions and examines what happens when those assumptions no longer hold. Through concrete examples drawn from modern C++ — including ranges and views, type erasure, allocators, and other common abstractions — we will examine how factors such as optimizer visibility, inlining boundaries, allocation behavior, and runtime flexibility influence performance.

This talk treats abstraction as a powerful engineering tool, examining the limits of its zero-cost guarantees in real-world systems. We will look at how seemingly small design choices can introduce hidden costs, why those costs are often difficult to spot through inspection alone, and how to recover performance without abandoning good design or readability.

Attendees will leave with a clearer understanding of when abstractions are truly zero-cost, how to recognize situations where they are not, and how to make informed tradeoffs between expressiveness, flexibility, and performance in modern C++.

Choosing cache-friendly data structures is a well-known optimization, but it's rarely the whole story. This talk goes deeper, exploring the hardware mechanics that dictate real-world performance and showing where significant gains are still left on the table.

We'll start from the ground up: what actually happens inside the cache hierarchy when your code issues a memory read or a software prefetch? Understanding the hardware lets us answer, when you should prefetch manually, and when you should trust the hardware prefetcher.

From there, we'll examine the invisible cost of multi-core C++. Cache coherency protocols (MESI/MOESI) can silently degrade performance through false sharing, RFO stalls, and coherency storms. We'll walk through how to diagnose these issues using hardware performance counters and how to eliminate them.

Additionally, we will contrast these behaviors across the data cache (DCache) and instruction cache (ICache), and analyze how Translation Lookaside Buffers (TLBs) impact overall memory read latency.

Finally, we'll tie it all together by combining hardware insight with application profiling data to arrive at practical strategies for low latency C++, packaged as an application-aware memory allocator.

This talk takes you through the research and optimization of radix sort, culminating in its integration into libc++.

You will learn : common pitfalls of radix sort implementations (non-binary digits, dynamic memory allocation, fragile interfaces), how to design a strict and high-performance interface (fixed digit size, external buffer, projection to integers), and how to overcome radix sort's main drawback — its lack of naturalness — with two counter-based optimizations and a hybrid merge scheme.

The result : on arrays of 60 int32 elements (18 for int8), radix sort starts beating std::sort ; on large arrays, it's up to 10x faster. Floating-point types (float/double/float16_t) are also supported via IEEE 754 bit transformations (sign and exponent inversion for negative numbers).

The key takeaway : in modern libc++, for integers and floats, std::stable_sort on random data is noticeably faster than std::sort . Life has become better, but also more complicated — choose your sorting algorithm wisely.

For a long time, programming was constrained by our ability to produce code. That constraint is eroding rapidly. AI systems can now generate substantial amounts of code with little effort, while inspection, validation, and integration remain difficult.

This transition alters the economics of software engineering. Code is becoming easier to generate than to reason about, and sound judgment grows scarcer relative to specialized intelligence. The emphasis shifts from authoring programs to understanding systems: their structure, invariants, interactions, and long-term evolution.

The talk examines this transition through the lenses of history, language design, and recent developments in AI and metaprogramming. It argues that the central challenges ahead concern not code generation, but the management of complexity at scale.

Topics include: - historical parallels and failed predictions in computing - AI-assisted software development - language design and metaprogramming - C++ reflection and compile-time programming - abstraction as context compression - complexity management in large systems

AI will undoubtedly transform how we build software. As before, the decisive factor will be our capacity to adapt.

As legacy C++ codebases evolve to meet new requirements, fix architectural issues, and address performance bottlenecks, refactoring becomes inevitable — but full rewrites are risky, costly, and rarely practical. This talk explores how modern C++ features — especially functional programming techniques and type erasure — can be used to refactor and extend legacy systems. We will present a concrete, low-risk, and measurable four-step technical framework for incremental modernization, by leveraging pure functions, discriminated union types, and type-erased callables to achieve safer, more flexible code with compile-time guarantees, even in traditionally object-oriented codebases.

The core of the talk will walk through the entire process on a concrete code example, illustrating (1) how to isolate existing logic, (2) define safer data models using immutable types, (3) deploy type erasure to create a robust, non-disruptive adapter boundary between old and new code, and (4) measurably execute the migration with safe testing practices. We will also share lessons learned from real-world experience and conclude by showing how these foundational patterns can be extended into future-thinking designs, leveraging examples with accepted C++26 features. Every step is grounded in real production constraints and trade-offs, and the techniques transfer directly to any domain where full rewrites are not an option. Attendees will walk away equipped with practical strategies to incrementally refactor your legacy systems without sacrificing stability or velocity.

C++26 is often defined by its headline features — reflection, contracts, and senders/receivers. But those don’t tell the whole story.

In this talk, we’ll look beyond the headlines to explore the changes that more accurately reflect where C++ is heading. While less visible, these features address long-standing pain points, improve consistency, and quietly reshape everyday programming in C++.

We'll examine the continued expansion of constexpr, including the ability to throw exceptions at compile time, and what it means for the boundary between compile-time and runtime. We'll also discuss the evolving model of erroneous behavior and indeterminate values, making it more explicit what constitutes incorrect code — and how implementations can reason about it.

Safety is also becoming a stronger focus in the standard library. With the introduction of library hardening, C++26 takes steps toward making incorrect usage easier to detect and harder to ignore, without sacrificing performance.

Along the way, we'll look at improvements to function wrappers with std::function_ref and std::copyable_function , enhancements to structured bindings, and the growing capabilities of std::format . We'll also cover pack indexing and its impact on template expressiveness, as well as the ongoing expansion of the freestanding library.

Rather than focusing on individual features in isolation, this talk connects them into a broader narrative: the real direction of C++26 — toward greater clarity, expressiveness, and safety in everyday code.

In December I posted a short video every day about a different compiler optimisation. Some were obvious. Some surprised me. A handful caught me out completely, and some even were compiler bugs!

This talk distils the most interesting into one talk. It isn't a clip show: the order matters, the gaps matter, and together they tell a story about where modern optimisers are scarily good, where they're stubbornly bad, and where that gap has moved in the last few years. With outtakes about what didn't make the cut and what I got wrong on camera.