CppCon 2026

Software development has now shifted decisively to a distributed, asynchronous paradigm, in which engineers must manage code that may be executing on parallel threads, or on a different machine. Many mainstream programming languages have adapted themselves to this new world. For example, JavaScript has promises and async/await, Python has asyncio, Rust offers zero-cost async/await with compile-time safety, and Go built goroutines and channels as first-class primitives.

C++ developers face the same challenge but have been left without a standard solution. As a result, much production code remains stuck in “callback hell,” where control flow is inverted, error handling is duplicated at every level, and common patterns like "run A and B in parallel, and then combine results" must be hand-rolled every time.

This is not simply a matter of bolting async/await onto C++. Deterministic destruction, zero-overhead abstraction, and precise control over memory and lifetimes, these very properties making C++ powerful dictate that an async framework cannot rely on a garbage collector or managed runtime to paper over complexity. It must earn its place by working with the language's ownership model, not around it.

std::execution is C++’s answer to this problem. Introduced as part of C++ 26, it solves this through composable senders: lazy, type-safe descriptions of work that can be chained, branched, and parallelized before being submitted to an execution context. Like Swift's structured concurrency, std::execution enforces structured lifetimes so that async work cannot silently outlive its scope.

This talk aims to provide application developers with an introduction to the current proposal and give them a grounding in the fundamentals that can be applied in real-world applications. We will walk through several worked examples: from simple chains to parallel fan-out with error propagation, showing side-by-side comparisons with callback-based equivalents to make the advantages more concrete and relatable.

This talk assumes no knowledge of the std::execution framework and no expertise in async programming, though practical, real-world experience will certainly help ground the examples. Attendees will leave with a working understanding of the sender/receiver model, practical patterns they can use, and a clear picture of what structured concurrency means for C++.

Developers of large C and C++ projects have to choose between two main development paradigms: component based development and monolith based development, each one with its own advantages and disadvantages.

In component based development, projects can be split in multiple repositories that allow to do decouple development and releasing, which suits well for many organizations that split the work in different teams with different development speeds. But this approach requires efficient dependency management, complicates working simultaneously in multiple components and it adds extra challenges to implement Continuous Integration at scale.

On the other hand, in monolithic/monorepo base development, the build system tool manages the whole project efficiently, simplifying some development and integration flows. But it can be resource-intensive on the CI side and it also push the whole organization to move at the same speed, often with little or almost no versioning: the “live at head” paradigm

It is said that by Conway's law, organizations are forced in practice to choose between them. But what if modern C and C++ tooling allowed us to have the best of both worlds?

This talk will present the novel Conan2 “Workspaces”, a monolithic view of multiple independent components that can be dynamically added and removed from the monolithic build, and how leveraging CMake FetchContent, such a single monolithic build can be implemented.

Also, for the cases where not only CMake is involved, a quick overview of the orchestration of workspace incremental builds for heterogenous build systems and CI at scale will also be introduced.

The talk will describe the basics, tools, design and architecture of the solutions, and it will also show full working demonstrations for them.

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.

Modern coding agents are incredible, but they still struggle with the kind of large, unstructured codebases that are common in C++. There are several techniques and tools that can make them perform much better. Here we show examples and demos of how to get your agent to work better with complex code. The focus is on providing an overview on current techniques and how we’ve found they work best. - Skills, memory and MCP - these have all been hyped hard, we’ll sort through where they are actually useful. - All agents (Claude, Copilot, Codex, Gemini) support these - some better than others. - What a skill is and what it isn’t - How to use persistent memory - Why MCP servers are still needed (but not always) - Context engineering. - Context management keeps changing - we’ve got autocompaction and 1M token windows now, why should we care anymore? - When to “manage” your agent’s context window and when it’s a bad idea - How to understand where context is being spent. - How and why to use subagents - these are almost always available but the capabilities in different frontends are exposed in different ways. - Spec Oriented Development: buzzword, euphemism for vibe coding or the future of programming? - What is it? - What tools exist? Covering options such as SpecKit, Kiro, etc. - Working in parallel with agent teams! - How to get started without having to learn anything (almost)! - Runtime context. - How to give your agent the best possible feedback path so you can stop micromanaging it and leave it to complete longer, more complex tasks. - Techniques including testing, CI integration and recording-based technology