CppCon 2026

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.

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.

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?

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.