CppCon 2026

TBA

Meet outside of Aurora BCD immediately after the opening keynote to be in the conference photo. Be part of conference history!

Photo will be taken by CppCon's official conference photographer, Jonathan Phillips.

Move semantics and perfect forwarding, introduced in C++11, are quite impactful features that still remain a source of confusion even for some experienced developers. This talk builds understanding from the ground up: what problem move semantics solves, how rvalue references enable it, and why the rules work the way they do.

We start with the cost of unnecessary copies and how move constructors and move assignment operators let us transfer resources instead of duplicating them. We then look at how std::move doesn't actually move anything — and what it really does. From there we tackle the forwarding problem: why writing a single function that preserves the value category of its arguments is necessary, how forwarding references (also known as "universal reference" in the past) solve it, and what std::forward does under the hood.

Along the way we cover the practical details that trip people up: reference collapsing rules, the interaction between overload resolution and reference binding, when the compiler generates move operations and when it doesn't, and the cases where std::move can actually pessimize your code. We also discuss trade-offs in parameter passing — by value, by const reference, or by forwarding reference — so attendees should have a clearer model for making these decisions in their own code.

At the end we will look into std::forward_like and explore how it is different from std::forward .

No prior knowledge of rvalue references is assumed. Familiarity with copy constructors, destructors, and basic templates is helpful.

A chess engine must search millions of positions per second. Move generation is often a bottleneck. Generating moves for knights, kings, and pawns are computationally cheap (~1 nanosecond). However, rooks, bishops, and queens (aka "sliding pieces") present a unique challenge: their movement depends on the placement of other pieces. This makes on-demand generation too slow (20+ nanoseconds) and naively-implemented lookup tables impractical (requiring zettabytes of RAM).

We will start by reviewing the core data structures in a chess engine and the logic behind move generation. Then, we will explore "magic bitboards", a perfect hashing technique that enables sliding piece move generation in ~1 nanosecond. We will look at how to implement this in modern C++, comparing hardware-specific instructions like PEXT (Parallel Bits Extract) against a portable software approach. Finally, we will discuss the practical challenges of generating the data structures required for magic bitboards, including the limitations of consteval and how to integrate build-time table generation into the build process using Bazel.

To ground these concepts, we will be referencing implementation details and code from my C++ chess engine, FollyChess.

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++.

What does it take to build a real-time embedded control system in modern C++, simulate its environment, command it from a browser, and watch it fly in 3D — all from the same open source ecosystem? This talk follows that pipeline end-to-end: from a C++23 real-time framework that schedules deterministic control loops across POSIX hosts and bare-metal microcontrollers, to GPU-accelerated simulation with CUDA, to web-based operations and telemetry, to live 3D visualization in Unreal Engine.

Attendees will see how a unified runtime architecture can span embedded control, simulation, diagnostics, operations, and visualization without fragmenting into separate software stacks. The talk explores deterministic scheduling, zero-allocation real-time design, cross-platform deployment, and integrating CUDA compute kernels directly into scheduled control loops without blocking execution. It also covers tooling for validating deterministic real-time behavior, along with techniques for streaming telemetry and sensor data between simulation and visualization layers in real time.

The presentation includes live demonstrations of a quadcopter simulation flying a programmed trajectory with lidar feedback, and a full-fidelity aircraft simulation with closed-loop autopilot, engine dynamics, and atmospheric turbulence — both running through the same real-time framework and rendered live in Unreal Engine. Whether you build flight software, robotics systems, industrial controllers, or simulation infrastructure, this talk presents practical architectural patterns for modern real-time systems in C++ that bridge embedded devices, GPU compute, and interactive visualization.

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.

Queues are the backbone of concurrent systems — yet most C++ developers treat them as a black box. Pick the wrong queue topology, misplace an alignas, or use the wrong memory order, and you pay for it in microseconds of latency, invisible cache thrashing, or subtle correctness bugs that only manifest under load. This talk is a rigorous, bottom-up treatment of the four canonical concurrent queue topologies: SPSC, MPSC, SPMC, and MPMC. We start with the hardware reality — how cache coherence protocols turn innocent struct layout into a performance disaster through false sharing — and build upward through the C++ memory model, atomic operations, and queue algorithm design. For each topology, we derive the minimal set of memory ordering guarantees required for correctness, show how to exploit producer/consumer asymmetry to eliminate unnecessary synchronization, and demonstrate how alignas(std::hardware destructive interference size) and deliberate padding can be the difference between 100ns and 10ns throughput. We dissect Dmitry Vyukov's MPMC ring buffer, the intrusive MPSC queue, and Michael-Scott's linked-list queue — not just their interfaces, but the why behind every memory order acquire and every phantom cache line. We then go beyond correctness into the practical engineering tradeoffs: bounded vs unbounded, throughput vs latency, contention vs coordination overhead. Real benchmark data shows how these decisions interact non-obviously — an MPMC queue can outperform MPSC under certain producer counts, and seq cst where you don't need it can quietly halve your throughput. Attendees will leave with a clear mental model for choosing and implementing the right queue for their threading topology, a checklist for false sharing audits, and battle-tested code patterns suitable for low-latency production systems.

C++ templates are one of the language’s most powerful yet often misunderstood features. This talk walks the audience through the entire template landscape, starting with the basic syntax and definition, moving through function and class templates, and culminating in advanced techniques.

Attendees will learn how template argument deduction works, why implicit requirements matter, and how explicit specialization can replace error-prone macro tricks. Real-world examples, including a flexible register abstraction used in production code, show how generic programming can deliver type-safe, high-performance solutions without sacrificing readability and performance (zero cost abstraction).

By the end of the session, participants will feel confident writing their own generic components, understand the trade-offs of different template features, and have a toolbox of best-practice patterns they can apply immediately to their projects.

Getting a project approved, or killed, often has less to do with technical merit than with who actually holds the keys and what they need to hear. This talk draws on real case studies from library design fights, cross-functional infrastructure rewrites, and a couple of notable failures to show practical techniques: how to find the real decision-maker, how to break expert deadlock with a position paper, and how to build toward an audacious goal through incremental wins and a well timed crisis.

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.

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.

Some of the most expensive C++ bugs are not caused by obscure language features. Instead, they emerge from code that looks reasonable: shared ownership that quietly extends lifetimes, singletons that become invisible dependencies, and performance-driven decisions that harden into architecture.

This talk examines these common design-level failure patterns in large-scale C++ systems. We cover three concrete design shifts:

Lifetimes: Shifting from shared ownership to explicit lifetime boundaries. Coupling: Shifting from implicit global coupling to injected dependencies. Interfaces: Replacing permissive APIs with constrained interfaces using std::span, std::optional, std::variant, and strong types.

Each shift is presented with the failure pattern it addresses, the solution, and the design rule it yields. Attendees will leave with practical heuristics for designing systems that are easier to reason about, test, and evolve: all grounded in real-world failures and the redesigns that fixed them.

In the C++ ecosystem, we have powerful tools for understanding our programs before, during, and after they run. But compiler warnings, clang-tidy, cppcheck, sanitizers, debuggers, profilers, and coverage tools all answer different questions, and using them well starts with knowing which question you are asking.

This talk introduces code analysis from first principles. We will compare static techniques such as compiler diagnostics, linting, and include analysis with runtime techniques such as sanitizers, coverage instrumentation, and profiling. We will also briefly connect these tools to the direction of modern C++, including C++26 contracts and standard library hardening, where some assumptions that used to live only in comments, documentation, or debug modes become part of the program's checkable structure. Through small C++ examples, we will see what each category of tool can reveal, what it cannot prove, and how the tools complement each other.

Attendees will leave with a practical mental model for choosing the right analysis tool for the task at hand, interpreting its output, introducing analysis into an existing C++ codebase, and writing code that is easier for both humans and tools to understand.

The architecture of legacy compilers presents limitations for modern software development. As codebases scale, developers face increased compilation times. While language complexity is often cited, key architectural bottlenecks include pointer-chasing across deeply nested ASTs (cache misses), single-threaded type resolution, and significant thread-lock contention (RwLock) during parallel semantic analysis. What happens when we discard the Abstract Syntax Tree entirely and apply strict Data-Oriented Design to the compiler itself?

In this session, we will explore the internal architecture of the Vx compiler frontend—a heterogeneous systems programming language to safely maximize utilization of available CPU cores. We will dissect how to translate complex, tree-like program semantics into flat, contiguous arrays of 256-bit bit-packed Global Identifiers (GIDs).

By stepping away from traditional recursive tree-walking and object-oriented compiler design, attendees will learn how to implement high-throughput parallel pipelines.

This talk is not just for language designers. The architectural patterns used to build the Vx compiler—flattening graphs into arrays, deferred identity, and lock-free synchronization boundaries—are directly applicable to any C++ developer building high-performance, multithreaded systems.

Building on the recent work of improving the quality of Sea of Thieves' codebase by upgrading from C++14 to C++20, this talk will focus on the work that has went into enabling warnings as errors on the game, and more.

Rare will discuss the motivations behind wanting to crank up the warning level, and to flick the "warnings as errors" switch after 10 years of development in their multi-million line Unreal Engine code base.

What were the challenges? How much effort did it take? Was it worth it? Did we find any bugs? Did we stop at just "/W4 /WX"? What warnings did we find the most useful? What warnings were deemed unhelpful? All of these questions and probably more will be answered throughout this session.

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.

For C++ developers building modular applications or performance-critical loops, modern architecture often forces a painful compromise: you either build heavily decoupled systems that thrash the CPU cache, or you write rigid, tightly coupled code. Distributed builds mask the compile-time symptom — but the underlying coupling bleeds into the runtime hot path.

This talk presents the Capability Routing Grid (CRG), an architecture that refuses this compromise. CRG enables a zero-registry plugin system where modules self-register at link time, and polymorphic dispatch is reduced to an O(1) branchless array lookup — with no central registry, no Init() function, and no runtime search.

Three independent pillars, each usable standalone:

Pillar 1 — Linker-Driven Discovery: Build a fully decoupled plugin system without central registries or Init() boilerplate. Modules self-register via standard C++ static initialization — entirely automatic in monolithic builds, and requiring a single explicit sync-point call at DLL load time.

Pillar 2 — State and Behavior Separation: Enforce a strict architectural boundary between pure data structs and stateless capability objects. This separation — not a framework — is what keeps the hot path flat. Type erasure is available as an optional cold-path utility for cross-boundary routing, but is never required for performance.

Pillar 3 — O(1) Branchless Dispatch: Map multi-dimensional contextual states into a single flat lookup table using basic polynomial math. Because this layout never changes, the CPU branch predictor and hardware prefetcher maintain peak efficiency.

The final payoff: by collapsing capabilities into raw function pointers, the system hits the memory bandwidth ceiling — 33 GiB/s sustained throughput, with a per-dispatch tax of approximately 1.5 nanoseconds.

Data-Oriented Design is defined from scratch. A brief hardware cache primer precedes every performance claim. The entire architecture compiles on C++17 — no language extensions, no experimental flags, on any mainstream toolchain. The audience will leave thinking, "I could have written this" — because they can.

Attendees will learn how to: - Build self-registering plugins with zero shared headers, using standard static initialization across both monolithic and DLL builds - Apply state/behavior separation as an architectural discipline — keeping capabilities stateless and the hot path free of virtual overhead - Replace vtable dispatch with a flat array lookup across N behavioral dimensions — O(1) regardless of dimensionality - Cache resolved logic as raw function pointers and call them directly, reaching memory-bound throughput

Memory leaks are very hard to treat. We have reliable tools like valgrind or AddressSanitizer to tell us whether or not an application has leaked memory, but current tools cannot tell us where the leak happens (they can tell us where the allocation happened,which is not the same).

I show that it is possible to run an analysis that is equivalent to running a garbage detection pass after every instruction and use that to find the actual cause of memory leaks in open source applications.

Using a garbage detection algorithm on record-and-replay recording, one can overcome the most obvious obstacle: stopping a program a program after every instruction or running garbage detection algorithms is very slow, but we can effectively run a bisection search on the recorded timeline to avoid having to evaluate after every instruction.

The goal is attribution to source code. Are we limited to reporting the instruction that overwrites the last reference to allocated memory or can we actually diagnose a specific error for a concrete function?

C++ gives us at least four different ways to pass "a thing that can be called" from one piece of code to another: function pointers, function objects, lambdas, and type-erased wrappers like std::function . Modern C++ has added more — generic lambdas, deducing-this lambdas, std::move_only_function , and a healthy ecosystem of concept-constrained callable parameters. Each of these has a job it is good at and several jobs it is bad at, but they are often used interchangeably until something breaks.

We will start with the basics: what a callable actually is, how function pointers, function objects, and lambdas relate to one another, and how the compiler thinks about each of them. We will look at lambda capture rules in detail — by-value, by-reference, init captures, dangling captures, and the cases where well-meaning developers reach for [=] or [&] and ship a bug — and we will see how generic lambdas (C++14) and deducing-this lambdas (C++23) extend the model without giving up clarity.

From there we will turn to the question of how to store and pass callables. We will compare function pointers, std::function , std::move_only_function (C++23), and concept-templated callable parameters along the axes that actually matter: ownership, allocation, move-only support, performance, and what the API tells the reader. Examples will be drawn from issues that have come up writing production code and mentoring developers — including the kind of subtle ABI and lifetime bugs that hide behind a perfectly reasonable-looking std::function<void()> parameter.

We will conclude with recommendations for which tool to reach for in which situation, with reference to the C++ Core Guidelines where useful. Attendees will leave with a clearer mental model of callables in modern C++ and a defensible default for the next time they write a function that takes one.

Was generating lines of code / upping the commit count the major impediment to delivering stable production ready software?

AI-assisted development has lowered the barrier to churn out code, helped engineers move faster in unfamiliar codebases, and made legacy systems easier to approach. however increased code output does not automatically mean better delivery of more reliable code.

In this talk, we will look at some of the emerging problems that are now becoming evident with AI ***amplifying existing weaknesses** such as code duplication, larger pull requests and the temptation to accept plausible generated changes without sufficient scrutiny . AI does not remove the need for engineering judgment. It removes the friction that used to slow down code creation

We will explore practical lines of defense to effectively reinforce long-term codebase health including stronger pull request descriptions, shared reviewer responsibility, review checklists, and metrics

The goal is not to reject AI. The goal is to ensure that AI improves engineering delivery rather than accelerating technical debt.

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++.

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

Application developers sometimes hit a limitation of a 3rd-party library or framework. The Type Erasure design pattern can help us overcome such limitations without the need to change the 3rd-party API.

Type Erasure is a relatively complex design pattern that allows us to treat a set of unrelated classes as if they shared a common base class, while preserving value semantics. The downside is increased code bloat and code complexity as the pattern requires a significant amount of additional code.

There have been quite a few talks explaining HOW to implement Type Erasure, while the topic of WHEN has been rarely discussed. Should we always use type erasure instead of virtual polymorphism? And if not, then what are the criteria?

This talk will show a concrete example from the audio programming industry of how Type Erasure allowed adding new functionalities to the parameter class system of the JUCE C++ framework without changing its API. As such, the talk will be useful for application and library developers who use 3rd party libraries but need an extra degree of flexibility.

You will come out of the talk understanding

• what Type Erasure is,
• when to use it, and
• how to implement it.

You don't need to understand Type Erasure, audio development, or JUCE to attend the talk; the necessary minimum will be explained during the talk.

Every C++ developer runs their build system dozens of times a day, yet few think about what it actually computes. Underneath every cmake --build or ninja invocation lies a directed acyclic graph, a DAG of dependencies that determines what gets rebuilt, in what order, and how much parallelism is available. When builds are slow, when incremental rebuilds trigger more work than expected, or when CI bottlenecks in surprising places, the root cause is almost always a structural property of this graph. Most developers never look at it.

This talk makes the build graph visible and actionable. Through curated examples, we will visualize dependency graphs and expose the common pathologies: overly connected "hub" headers that invalidate half the build when touched, deep critical paths that starve parallelism even on a 128-core machine, and accidental edges introduced by includes that no one questioned. These are not just build performance issues: they are architectural issues wearing a different hat. Your build graph is the ground truth of your codebase's structure, whether or not it matches the diagram in your team's documentation.

Armed with this mental model, we will walk through practical techniques for reshaping the graph: measuring critical path length from .ninja_log , identifying high-fan-in nodes, breaking costly edges with forward declarations and interface segregation, and using graph analysis as an automated architectural fitness function in CI. Worked examples will show concrete before-and-after measurements. You will leave with a new way of seeing your codebase, not as files in folders, but as a graph you can visualize, measure, and deliberately reshape.

HRT is excited to be back at CppCon again this year! We invite you to attend our Networking Social.