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.

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?

An overview of contemporary hardware platforms and how software engineering and design practices and methodologies could help in building performant systems, with a particular focus on low level optimizations. Contrary to attempting direct low level software engineering for addressing performance specifics, this talk would focus on how higher level abstractions could and should be used, and how a software engineer could help the compiler to “do the right thing”. The trend of moving software engineering focus upward to constructs that have a tendency of hiding the specific of the underlying platform is quite clear – and there certainly are very good reasons for such a paradigm change.

Performance matters. Premature optimization is evil. Is there anything in between those two extremes? How feasible is it to rely on the abstraction of the platform as hidden by the compiler and the corresponding libraries and language constructs, expecting that it will be able to realize the intended lower level optimizations? How much of hints and specifics would one need to expose for the compiler to be able to get the equivalent of direct low level approach? What is the right balance between expressing application logic via higher level construct yet still being able to gain the performance benefits compared relying on the low level specifics?

Looking from the practical applicability of lambdas, iterators, ranges, coroutines, error handling, and safe(r) memory access, the talk would attempt to cover a set of use cases with a focus on analysis of what could be done for focusing on performance.

The overall goal of the talk is not to go deep into low level aspects; the goal is to explain that one needs to be aware of such low level details while operating on the higher level constructs.

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.

C++ is adding major expressive power (e.g., reflection) and addressing weaknesses (e.g., memory safety hardening) at exactly the moment when chip supply and power budgets are raising the value of what people came to C++ for in the first place: control over memory layout (space) and deterministic performance (time). This talk is about that convergence, in two parts.
First, we cover the latest developments in ISO C++ itself, where the committee completed technical work on C++26 in March 2026, and then in June voted the first additions into the working draft for C++29:

• Key C++26 language improvements like reflection and the initial round of memory safety hardening, and standard library performance enhancers like std::simd and std::execution.
• A new Annex in the C++29 working draft cataloging every case of core language undefined behavior, the first step toward addressing it systematically rather than one paper at a time.
• Draft “profiles” for stronger portable memory safety guarantees, now being prototyped and targeted at C++29.

Second, we consider how quickly both hardware and software are moving in the industry around us. This year, capital is pouring into silicon and power at a jaw-dropping rate, and agentic systems are arriving with new capabilities and new failure modes. We’ll see how both affect C++ programming in the trenches:

• Why performance efficiency has been enduringly important, from the 1940s through to today and with no end in sight.
• How current industry data (SlashData, IDC) documents sustained growth in demand for professional programmers, especially who know languages that can operate under real space and time constraints.
• What AI does and doesn’t change about any of it: a pragmatic view both of where AI has shown real benefit in our programming world, and of what it’s not good at (yet, or ever).

Throughout, we might hear a little grumbling from the speaker about how he has always written his own talk titles and abstracts and prose using em-dashes, but now can’t use em-dashes anymore because of, well, you know.