CppCon 2026

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.

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.

C++ Views were introduced with C++20 and extended with C++23 and C++26. They are lightweight objects that specify how to use (specific) elements of collections and their values. By composed into pipelines, programmers can easily define complex processing of collections of data.

However, the use of views also has pitfalls and traps. Therefore you should know about * The consequences of reference semantics * The problems of caching Views * The problems of using const with views * The Filter View Fiasco

This talk gives an overview about both the technology and where to pay special attention.

The next evolution of C++ has officially arrived, bringing a massive wave of enhancements to both the core language and the Standard Library. But with hundreds of committee proposals officially baked into the standard, where do you start? Continuing the tradition from previous releases, this fast-paced session delivers a comprehensive look at the new and updated features that define C++26.

We won’t get bogged down in the minutiae of every single ISO proposal—covering everything in detail is impossible in just one hour. Instead, you'll get a high-level, curated overview of the most impactful changes, from the major game-changers down to the small quality-of-life gems. If you want to get up to speed with the new standard and see how it will shape your codebase, this session is for you.

The session will touch on the following core language and Standard Library topics.

C++26 core language changes include - Reflection - Contracts - Unnamed placeholder variables - = delete("reason"); - Pack indexing - #embed - constexpr exceptions, constexpr placement new - Variadic friends - ...

C++26 Standard Library changes include - Execution control library - New libraries such as , , , , , and more - std::inplace vector: dynamically-resizable vector with fixed capacity - std::philox engine: counter-based random number engine - std::text_encoding: text encodings identification - More constexpr for containers and container adaptors - Saturation arithmetic - New SI prefixes - Printing Blank Lines with std::println() - ...

Where applicable, I’ll point you toward other specialized CppCon sessions for those ready to dive even deeper into specific topics.

The C++ standard is moving more and more in the direction of safety. In the process, the committee is providing us with tools to help make our own code safer.

Many of these tools are specifically around numerics and none of them are enabled by default! To make matters worse, most C++ programmers don't even know these library features exist! Even if they did know, they wouldn't use them, because they are far too wordy.

We're going to do a survey of the relatively recently added new numeric safety related language features and see how they might come together in a real-ish project.

To write the best C++ application code, you must think like a library author. This talk reframes application development as a form of library design, where every component is a potential asset for future maintenance and extension.

We'll survey the C++ language features that empower library authors to create powerful, flexible, and safe abstractions. From there, we'll distill the 'library author mindset.’ You will leave with concrete principles and techniques to make your application code more modular, maintainable, composable, reusable, testable, and ultimately, more valuable.

How to Choose and Use the Right Container in Modern C++: Part 1, Classic Containers

Choosing the right container and using it correctly can have a profound impact on the performance of a program, but doing so is harder than you might think. In Part 1 we will survey the containers and adaptors in the C++17 Standard Library, and discuss how to choose the best tool for the job and extract the best performance from it. We will consider the abstractions they model and the practical limitations they impose, and find that choosing between them requires an understanding not only of the speed and size tradeoffs of each container, but also of the difference between algorithmic complexity and actual behavior. And we will flag aspects of the standard containers that, without this understanding, can lead you to the wrong choice.

How to Choose and Use the Right Container in Modern C++: Part 2, New and Future Containers

Choosing the right container and using it correctly can have a profound impact on the performance of a program, but doing so is harder than you might think. In Part 2 we will survey the new containers and adaptors introduced to the Standard Library in C++23/26, and discuss how to choose the best tool for the job and extract the best performance from it. We will consider the abstractions they model and the practical limitations they impose, and find that choosing between them requires an understanding not only of the speed and size tradeoffs of each container, but also of the difference between algorithmic complexity and actual behavior. And we will examine a proposal for a future container that diverges from the historical STL design principles and ask: what makes for a good container design?

The White House says stop using C++. CISA wants a memory safety roadmap. The internet says rewrite everything in Rust. Meanwhile, embedded teams are shipping firmware on Cortex-M microcontrollers with limited flash, no MMU, no virtual memory, and a codebase that cannot be rewritten overnight. So what do you actually do?

This talk is a practical, tool-by-tool walkthrough of every memory safety technique available to embedded C++ developers right now — and what is coming in C++26. It starts with what you can turn on today without changing a single line of code: compiler warnings that most projects still ignore, AddressSanitizer and UndefinedBehaviorSanitizer running on host-compiled firmware, and stack protection options that cost single-digit bytes of overhead. It then moves to code-level improvements that modern C++ makes possible: replacing raw pointer arithmetic with std::span, using std::expected instead of error codes that nobody checks, applying constexpr to move validation to compile time, and adopting strongly typed wrappers to eliminate unit-of-measure bugs. Finally, it covers what C++26 brings to the table — hardened standard library containers with bounds checking at 0.3% overhead, safety profiles for type and bounds and lifetime checking, contracts for defensive preconditions, and the elimination of uninitialized-variable undefined behavior — and evaluates which of these features are realistic for embedded targets today.

Every technique is evaluated on three axes: how much code do you have to change, what does it cost in code size and runtime on a real microcontroller, and what class of bugs does it actually prevent. Attendees will leave with a prioritized adoption checklist they can bring back to their team on Monday.

To navigate safely, a robot must simultaneously ingest high-frequency sensor data, compute complex spatial algorithms, and publish control commands. Historically, frameworks like ROS 2 have handled this via asynchronous callbacks. However, as autonomous stacks scale, relying heavily on unstructured callbacks can obscure control flow, making state synchronization difficult and robust task cancellation notoriously complex.

This talk explores how to transform unstructured, callback-based architectures in a robotics navigation stack into declarative pipelines using structured concurrency (specifically, C++ Senders and Receivers via stdexec). Attendees will dive into two real-world architectural examples: a collision monitor and a waypoint follower, showcasing readable logic pipelines, thread-hopping between an event loop and a static thread pool, and clean task cancellation.

Why does 0.1 + 0.2 not equal 0.3? Because binary floating-point cannot exactly represent most decimal fractions, the value 0.1 simply does not exist in IEEE 754 binary. For applications where rounding errors are unacceptable, finance, billing, regulatory reporting, scientific data interchange, this is a structural problem, not a precision setting that can be tuned away. IEEE 754-2008 introduced a decimal floating-point alternative that stores the significand in base 10, and ISO/IEC TR 24733 sketched a C++ binding for it. Compiler support, however, has remained uneven across vendors and architectures.

Boost.Decimal is a header-only, dependency-free, C++14 implementation of IEEE 754-2008 and TR 24733 decimal floating-point. It provides three IEEE-conformant types, decimal32 t, decimal64 t, and decimal128 t, and three companion decimal fast* t types that trade strict bit-layout conformance for speed where you don't need on-the-wire interoperability. All six types behave like built-in floating-point: they're constexpr-friendly throughout, support mixed arithmetic and promotion, and ship with their own implementations of , , , , , hashing, , and Boost.Math integration. The library is tested natively on x86 64, ARM64, and s390x, and under emulation on PPC64LE and ARM Cortex-M.

This talk is the introduction to decimal floating-point that most C++ programmers never got. We'll cover what decimal floating-point actually is at the bit level (BID vs. DPD encodings, the cohort concept that has no analogue in binary), why the standard library's defaults are what they are (e.g. Rounding), and how Boost.Decimal's API maps onto familiar and patterns. We'll work through worked examples, parsing a price feed, computing financial summary statistics through Boost.Math, round-tripping values through while preserving cohort information, and walk through the library's deliberate deviations from both IEEE 754 and the C++ standard, including why floating-point exception flags were sacrificed to keep constexpr and how from_chars was extended to distinguish overflow from underflow as well as preserve cohorts. We'll close with reviews of the benchmarks versus binary floating point, as well as other existing libraries.

By the end, attendees will know when reaching for decimal is the right call, which of the six types fits their workload, and what trade-offs the library made on their behalf.

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.

Language bindings for C++ can be valuable tools for developers who wish to make C++ libraries available for use in other programming languages, like Python. There are many reasons developers may wish to do this, including testing, prototyping, or performance.

One of the issues often faced when writing bindings for C++ is the need to write excessive amounts of boilerplate code to bridge the gap between the C++ types and interfaces and their equivalents in other languages.

Building on previous presentations, this talk will not just explore how you can use Reflection in C++26 to generate the necessary binding code, but also how you can integrate this into a CMake-based build system to enable the automatic generation of bindings for existing classes or libraries with minimal additions. We will present real-world examples, primarily using Python, to show how language bindings can be automatically generated, but we also show how this can be extended to other languages.

Most C++ programmers are familiar with the traditional C++ facilities for text processing found in the iostream and string libraries. However, std::format (C++20) and std::print (C++23) provide new text formatting tools that are unfamiliar to many C++ programmers. While these new facilities can be very helpful, they can also produce some very intimidating error messages when misused. Moreover, the process for writing your own user-defined types that you can format with std::format and std::print is not very straightforward.

This session starts with an overview of the traditional C and C++ text processing libraries. It then shows how std::format and std::print neatly combine benefits from both the C and C++ libraries to create a safer, more convenient interface. After that, this session explains the steps you must take to write user-defined types that work cleanly with std::format and std::print. You’ll leave this session with a clearer understanding of the benefits of using these new text formatting facilities and how to integrate them into your existing code base.

First day on a new project. You set up your workstation and then download a repository of over 1,000,000 lines of code. Even more intimidating, the code has been around for 20 years. Parts are in legacy C++, parts use the latest C++26 features, and increasingly, AI coding assistants are weaving new code through all of it, meaning some parts of the codebase may have never been fully understood by a developer. You feel overwhelmed. Don't Panic! In this talk, we share techniques and tools that real engineers use to find their bearings in code they didn't write, from the humble grep through debuggers and profilers to time-travel debugging and AI-assisted exploration. The audience will leave this talk with a mix of simple and advanced tricks for navigating large and complicated codebases.

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.

You found the perfect C++ library. But you cannot integrate it with your CMake build without reading three pages of bespoke instructions. The documentation (if any) is a Doxygen-generated API dump. You file a bug, get "read the source," and move on. You never adopted it—and you had every intention of doing so.

Or you are the author of that library. Technically brilliant. Six months after release: three users, no contributors, two support tickets, you are not sure how to answer. Drawing on years of experience as both a maintainer of mp-units — a high-visibility, standards-track C++ library — and as a developer who regularly evaluates and contributes to third-party C++ projects, I have watched this pattern repeat across dozens of technically excellent libraries. The barriers that drive users away, frustrate potential contributors, and quietly kill great projects are predictable. More importantly, they are fixable.

This talk traces the five stages every C++ library must survive — Discovery, Evaluation, Integration, Contribution, and Community — and examines the concrete engineering decisions at each. We will look at how naming, README structure, and CI signals communicate trust to a user who found you three seconds ago; how a properly fuzzed build matrix gives users real confidence across their compiler, their C++ standard, and their platform; how DevContainers and Compiler Explorer eliminate the local setup barrier for both users and contributors; how the Diátaxis framework turns a documentation site from a reference graveyard into a system that serves newcomers, practitioners, and design-curious contributors; and how to craft an AI contribution policy that manages the rising volume of LLM-generated PRs without sacrificing the architectural integrity that makes a library worth contributing to in the first place.

Whether you are a user evaluating libraries, a developer looking for a C++ project worth your time, or an author trying to build one, you will leave with a concrete, field-tested checklist.

C++ lifetime management is fundamentally built around synchronous scope exit. Constructors establish invariants, destructors release resources, and RAII permits ownership and cleanup to compose naturally with ordinary control flow. Asynchronous systems disrupt this model. Destruction may itself require asynchronous work, and “just launch another task in the destructor” quickly turns deterministic lifetime management into unstructured background activity.

This talk explores the implementation of async lifetime management in std::execution, based on the enter/exit scope sender framework proposed in P3955. Rather than treating async construction and destruction as special cases, the model reframes them as composable asynchronous protocols built around explicit async scope entry and exit operations. The talk follows the process of turning these ideas into working code, beginning from the low-level enter/exit sender abstractions and progressively assembling higher-level lifetime facilities on top. Along the way, the implementation uncovers an important self-similarity in the problem domain: Higher-level async lifetime facilities can themselves be expressed in terms of the same lower-level async lifetime primitives.

The implementation discussion focuses on the machinery required to make these guarantees real: Coordinating async teardown within structured concurrency, managing partially-entered scopes, and preserving deterministic cleanup semantics even when destruction itself becomes asynchronous. The resulting design serves both as a practical exploration of async lifetime management and as a case study in how implementing an abstraction can reveal deeper structural properties hiding inside the model itself.

Every mature codebase carries history and technical debt. The challenge is modernizing without stopping the world or introducing big re-write failure risks.

In this talk, we’ll explore how to modernize legacy C++ codebases incrementally using a mix of deterministic code transformations and AI-assisted refactoring .

After delving into some of the common problems with legacy modernization, we'll start tackling the simple "boring" stuff that deliver huge leverage of changes via clang tooling . These represent repeatable, deterministic reviewable upgrades that can be automated and applied at scale.

Then we can look at more difficult transformations that can be AI assisted with more aggressive transformations including API improvements and how to prevent it going off the rails. This will be backed by Compiler diagnostics, static analysis and testing to keep changes maintainable and correct .

The goal is not to replace engineering judgment, but to accelerate it: turning modernization into a continuous, low-risk workflow instead of a disruptive project.

Attendees will leave with a repeatable playbook for modernizing legacy codebases incrementally, safely, and at scale—using the right tool for each class of change

const is one of the oldest and most widely used features in C++, yet many developers still struggle with the subtle differences between const , constant expressions, constexpr , and consteval .

In this talk, you will learn how compile-time constants evolved in modern C++, starting with const and continuing through the features introduced since C++11. You will see what constant evaluation really means, what the compiler is allowed to execute during compilation, and where the limits still are today.

Using practical examples, we will explore when const is enough, when constexpr is needed, and how compile-time and runtime execution interact in modern C++. We will also look at common pitfalls, surprising behavior, and cases where compile-time programming can either improve code or make it harder to understand.

Finally, you will see how features such as consteval and std::is_constant_evaluated influence correctness, testing, and maintainability.

By the end of this talk, you will have a deeper understanding of constant evaluation and know how to use modern compile-time features more effectively in your code.

Most bosses aren’t stupid, they just seem like it sometimes! This can be especially so when a great programmer first becomes a manager – suddenly the very attributes that made them good at their job become a problem. Whether you’ve just been ‘promoted’ to a management position, you hope to be some day, or you want to know how to deal with a difficult manager – it’s very useful to understand the world from a boss’s perspective. Not all leaders are bosses (and not all bosses are truly leaders): if you want to get something meaningful done then you’ll need to influence other people.

Whether or not you're a boss, leadership is important. To do meaningful/large things, we need to work with other people. Encouraging and persuading peers in the right way will make your and your peers' working lives better.

Lots of war stories (anonymised to protect the guilty) and tips and tricks, this talk is basically 'how to win friends and influence people' for programmers.

The software in most embedded projects written in 2026 looks like the software in embedded projects written in 1996. This isn't because 1996 was the peak of innovation and quality but rather has more to do with biases and FUD. Unfortunately, much of the world suffers from these choices: users, developers, managers, and shareholders.

There are better ways to write firmware for embedded systems; proven techniques and implementation strategies that I will describe in this talk. We will explore techniques based on abstraction and composition that maximize understanding while reducing the codegen footprint. We will apply these strategies at all levels of the firmware stack: interrupts, register manipulation, peripheral communications, and the application glue.

Join me and leave with open-source libraries, an open-source starter project, and techniques that you can apply to your greenfield and existing projects.

Today's world runs on C++. That's because, in domains requiring scale, performance, low latency, and fine-grained control over concurrency, C++ is second to none! Yet in recent years, a growing concern has emerged: C++ programs are often considered unsafe — not because of programmer negligence, but because the language itself provides insufficient mechanisms to prevent or reliably detect undefined behavior (UB).

For those financially and technically invested in C++, its current lack of language safety raises a fundamental question: How can we evolve ISO C++ to be UB-safe without necessarily sacrificing runtime performance, and without breaking backward compatibility with existing, valid C++ code?

In this talk, we begin by motivating an overall approach to UB-safety that starts from a simple but uncompromising premise: each individual potential source of UB must be able to be detected via runtime checking. Crucially, this approach eliminates the notion of "safe" and "unsafe" regions of a program — there is no place where UB can hide, and no need to switch languages, subsets, or tools to achieve comprehensive coverage.

We then examine how the C++26 contracts facility provides the essential foundation for transforming optional runtime checks into the practical, scalable mechanisms to eliminate UB bugs in production software. Contracts give developers fine-grained control over where and when checking occurs, allowing runtime overhead to be spent where it is affordable or most valuable — such as in new, rarely executed, or security-critical code. These decisions naturally evolve over time, as long-running checks that never fire may no longer justify their cost.

Finally, we outline the concrete steps of an incremental journey toward reducing undefined behavior in ISO C++. The result is a model of UB-safety — rooted in C++26 contracts and optional runtime checking — that is competitive with, and in key respects stronger than, approaches taken by other high-performance languages. Most importantly, this model applies not only to new code, but to the vast body of existing C++ software already in the wild.

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.

For decades, lock-free programming has been the go-to optimization for the most contended parts of concurrent programs. The reasoning was simple: locks are slow under contention, so eliminate the locks. This made sense on the hardware of the time, and I should know—I've given several talks explaining how and why to do it. The hardware has changed. Modern CPUs are highly optimized for the operations that make locks fast: cache-line transfers, memory ordering, and speculative execution through lock acquisitions. To set the stage, we will briefly establish why, under high contention, a well-written lock consistently outperforms lock-free atomics and CAS loops. (As an aside, I'll hand you a concrete recipe for a spinlock that actually holds up under extreme contention—and show why systematic backoff, by batching cache-line ownership, is what protects the shared interconnect.) But the core of this talk addresses a completely flipped reality: at low contention, lock-free code decisively outperforms spinlocks, for the most surprising reason. Conventional wisdom assumes an uncontended spinlock is practically free. Using raw hardware performance counters, we will see why it isn't: the implicit synchronization a spinlock imposes—even with no contention at all—is deeply unfavorable to modern out-of-order pipelines, while a single lock-free XADD or CAS, an indivisible read-modify-write, is not. The path everyone assumes is free turns out to be the quietly expensive one. Putting these two facts together—locks winning high contention via cache-line batching, atomics winning low contention by staying out of the pipeline's way—points to a concrete design. I will present a highly optimized MPMC (multi-producer, multi-consumer) queue built on a dual-domain structure that deliberately segregates the contended path from the uncontended one, letting each run on the mechanism the hardware actually favors. We will then walk extensive benchmarks across modern silicon—Intel, ARM server (Graviton/Grace), and Apple (M3)—showing this queue is the fastest, often by wide margins, across most operating regimes. We will also see why the tradeoffs play out so differently per chip, in ways that aren't obvious from the spec sheet, and why "ARM vs x86" is the wrong axis entirely—what matters is the chip's target market, not its instruction set. Finally, no benchmark is complete without honest caveats. I will detail the specific corners where this design can still be beaten, the hidden system costs you pay elsewhere to buy this throughput, and why systems that strictly require progress guarantees—deadlock avoidance, priority inversion, safe execution in a signal handler—mean traditional lock-free programming is not dead. It has simply relocated. If you've ever reached for a complex lock-free algorithm to speed up a highly contended hot path—or wondered what your CPU is actually doing during a mutex unlock—this talk will change your mind about where lock-free programming truly belongs.

TBA