CppCon 2026

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.

Floating point has a reputation for betrayal. Change the thread count, vector width, compiler flags, reduction tree, or target architecture, and the low bits can move. Parallel algorithms make this worse: the standard often specifies the operation, but not the numerical expression whose result must be reproduced. This talk asks a provocative question: what if reproducible numerics did not have to be slow?

We will show reproducible, deterministic implementations of reduce and scan that exhibit better error behavior on hostile floating-point workloads and can match or beat conventional standard-library implementations on realistic workloads. The trick is not to freeze the execution schedule. It is to specify the expression being computed, then let the implementation use SIMD, threading, blocking, tiling, and platform-specific strategies to compute that expression efficiently.

The key idea, developed through C++ standardization work such as P4016R0 and P4229R0, is reproducibility by reproducing the computation. Instead of asking the implementation to promise a particular schedule, we give the calculation a named expression. Once that expression is chosen, changing the thread count, vector width, chunking, or blocking strategy does not silently change the answer.

A reproducible scan makes this harder than reduce because it does not expose only one final value. It exposes every prefix. A reproducible final sum is not enough if the intermediate results still drift. We will show how expression and observation contracts make those prefixes reproducible without forcing the computation back into a slow sequential order.

Then we go below the algorithm layer, to the places where bits usually escape: FMA contraction, denormals, floating-point environment choices, math-library approximations, and vectorized transcendental functions. The goal is not to get the same answer by turning off the hardware. We will show reproducible vectorized primitives, including transcendental functions, running at speeds comparable to established vector math libraries while preserving a cross-platform numerical contract.

Finally, we put the whole stack under stress: a heterogeneous numerical pipeline across x86-64, Apple Silicon, and CUDA. The data is deliberately hostile, with high cancellation rates and fragile intermediate states. The aim is not to pass friendly benchmark cases, but to reproduce the specified computation, including the same intermediate failures, not just the same final answer, bit for bit, across CPUs, GPUs, and toolchains.

C++26 introduces contract assertions: language-level constructs for expressing expectations about program correctness, optionally checking them at runtime, and configuring how violations are handled. However, what ships in C++26 is intentionally minimal — not the final destination, but a carefully designed foundation for a much more capable facility.

In this talk, we begin with a brief overview of contract assertions as they exist in C++26, including the three kinds of assertions ( pre , post , and contract_assert ), the four evaluation semantics ( ignore , observe , enforce , and quick-enforce ), and the user-replaceable contract-violation handler. The focus of the talk, however, is the next stage of evolution already underway.

We will explore the major extensions currently planned for C++29 and beyond, and the problems they are intended to address, and how they build upon the extensibility intentionally designed into the C++26 facility. Many of the concerns raised during standardisation — particularly around scalability, configurability, and expressiveness — are already being addressed by these extensions. We will discuss contract assertions on virtual functions; grouping contract assertions and configuring evaluation semantics by group; constraining evaluation semantics (for example, assertions that must always or never be enforced); postconditions that refer to earlier program state; user-defined diagnostic messages; and finally, compiler-generated, implicit contract assertions guarding against core-language undefined behavior. We then look even further ahead at more ambitious ideas still in earlier stages of exploration: class invariants, contracts on function pointers, and procedural interfaces.

Rather than just listing the proposed extensions, we will examine the design considerations behind them and show how the new functionality fits into the broader model of contract assertions in C++. What does it mean for contracts to participate in virtual dispatch? When can contract assertions support optimisation? How can evaluation semantics remain both predictable and configurable across large codebases? Understanding these questions is essential to understanding where contract assertions in C++ are heading next.

This talk is intended for anyone interested not only in how contract assertions work in C++, but also in the principles shaping their future evolution — and what a complete contract facility for C++ might ultimately look like.

For thirty years, SIMD has been the preserve of experts. Writing the fastest C++ has meant hand-written intrinsics, locking code to one architecture, and parallel implementations maintained across every instruction set you ship to. Auto-vectorization can help, but optimizers may give up in complex scenarios where iteration independence isn't obvious. C++26 changes that by putting SIMD in the hands of every C++ programmer, bringing portable, expressive data parallelism into the standard library.

For the engineers who have spent decades writing intrinsics in telecoms, finance, HPC, and embedded systems, migration to std::simd is only worthwhile if it preserves the performance they have fought to achieve. Every cycle counts when code runs tens of thousands of times per second, for years on end, and a portable abstraction that costs ten percent is not a win. The bar for adoption is therefore high: the abstraction must be measurably cheap, the generated code must match hand-written intrinsics, and the tricks and techniques those engineers rely on must all be expressible in the library, not lost in translation.

This talk takes the practitioner's view, aimed squarely at the engineers who write real intrinsics code today and need to know whether std::simd can replace it. It starts with what modern SIMD hardware actually offers, grounding std::simd in real silicon. It then works through the main features of C++26's std::simd with worked examples drawn from the patterns that recur in production intrinsics code, accessible to programmers new to the library and detailed enough for intrinsics veterans to map against their own kernels with all their accumulated tricks and techniques. A look under the hood at our implementation shows how careful API design and aggressive use of hardware features make the abstraction as cheap as the target architecture allows, and how the library fills the gaps on weaker targets with implementations that an expert library author can write once on behalf of every user. The talk closes with a preview of the C++29 proposals being written now to close the remaining gaps, so that std::simd becomes a clear win even for the most performance-critical code.

Building embedded systems wastes time on infrastructure instead of features. Before running application logic, developers lose hours bootstrapping init systems, wiring services, debugging startup failures, and fighting tooling never designed for constrained or early-boot environments. AEMBER is a developer-first PID1 (init system) that eliminates this overhead by providing a modern C++ runtime for process supervision, container orchestration, and service management - letting you focus on your application, not your plumbing.

This talk demonstrates how C++23 enables robust embedded systems without sacrificing performance. We'll explore std::expected for exception-free error handling, if consteval for compile-time optimization paths, and deducing this for zero-overhead policy classes. You'll see how monadic operations compose system calls into clean pipelines, and how modern C++ features build type-safe APIs for namespaces, cgroups, and process management.

Starting from main(), we'll trace AEMBER's architecture: how components compose, how errors propagate through std::expected chains, and how C++23 patterns enable embedded systems to be both safe and fast. We'll wrap up with a live demo showing AEMBER managing containers and services in real-time. You'll leave with concrete techniques for building maintainable embedded infrastructure using cutting-edge C++.

Scripting in a C++ game engine should not cost you the engine's native performance. This talk shows how C++26 static reflection and std::meta::substitute in particular can lift a scripting language's bytecode into C++ template structures that the compiler optimizes away entirely, collapsing the interpreter dispatch loop into the same machine code you'd write by hand. Scripting languages like AngelScript and Lua are invaluable in C++ engines: they give designers a fast iteration loop without rebuilding the engine. But they come with a paradox. The engine you chose for raw performance now spends cycles on every frame interpreting a slower language, juggling a software stack and checking types at runtime. We will walk through the technique step by step, starting from a plain bytecode interpreter and ending at a fully reflected program where a scripted sum(0..10) compiles to mov eax, 45; ret. Along the way you'll learn the core C++26 reflection primitives (^^, [: :], std::meta::substitute), how to assemble bytecode into structural templates like block<> and loop<>, and how these techniques generalize to embedding any stack or register based scripting language in your engine with zero runtime overhead.