CppCon 2026

Are you smarter than a branch predictor? In this interactive, game-show-themed session, the audience becomes the branch predictor: participants vote on which of two C++ snippets will run faster before we examine what actually happens on real hardware. The snippets are drawn from real-world production code, and correct answers are rewarded with unique specialty erasers (no two are the same!). Through these examples, we build a practical mental model of how modern CPUs handle control flow and why even small branching decisions can have a significant impact on performance. Using annotated assembly, performance-counter data, and cross-platform comparisons, this talk explores branch prediction, misprediction costs, indirect calls and virtual dispatch, and the trade-offs between branches and conditional moves. We examine how different compilers (GCC, Clang, and MSVC) transform code and highlight non-obvious cases where “branchless” code performs worse or behaves differently across architectures. The examples are intentionally small microbenchmarks, but each exposes patterns that appear in real-world systems when control flow becomes the bottleneck. Whether you're a systems engineer or just curious about what your branch predictor is doing behind your back, this session will give you a concrete mental model of control flow. You'll leave with the tools to profile your code, interpret assembly, and make informed decisions about when to rely on compiler heuristics versus manual optimization.

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.

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.