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

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

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.

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.

In modern C++, std::unordered_map is the de facto #2 container. Its dominance signifies a fundamental shift in application design: the performance-critical need for O(1) average-case key-value lookups.

Join as we move beyond "just use a hash map" and explore the critical, real-world implications of this choice. We'll start by benchmarking the classic std::map (red-black tree) against std::unordered_map (hash table) to understand exactly what you gain-and what you might lose.

However this power comes with risks. An average-case O(1) can quickly degrade to a catastrophic O(n) without warning. We will profile and dissect the actual costs of using a hash map:

• The Hash: What makes a good hash function? We'll go beyond std::hash and see how to write effective, fast hashers.
• The Collision: How do different collision-handling strategies impact performance and memory?
• The Re-hash: What is "load factor," and when does the hidden cost of a full table re-hash destroy your performance gains?

We'll conclude with a practical decision-making framework for when to choose std::unordered_map , when to fall back on the ordered std::map , and how std::string -the container we often forget is a container-fits into this modern landscape.

You will leave this session knowing precisely which data structure to deploy for maximum performance.

This talk presents some design choices, compromises, and optimisations of the implementations of std::flat map and std::flat set. It will cover a brief design history of the original paper regarding the class layout, libc++'s best effort to provide strong exception guarantee on those containers, compromise on the iterator choices between SCARY and more strongly typed, some optimisations on various operations and some tips about avoiding running some issues with these containers.

According to VGInsights, about 10% of games released on Steam in 2024 used a custom engine, but those games represent 41% of units sold. Most "how an engine works" talks come from the AAA end of that distribution. This one comes from the other end of that distribution: a teaching-scale engine, where every system has to be small enough to understand from first principles. The problems are the same as in a big engine, but the smaller surface is what makes the architecture legible.

In this talk, we'll walk the spine of the engine in modern C++: allocators and handles in the core, the job system, the graphics abstraction question, the asset pipeline split between pipeline-time and runtime, and scene representation including ECS. We finish on serialization, where C++26 reflection (P2996) offers a path past today's reliance on macros and external code generators.

Modern storage hardware has evolved at a breakneck pace. PCIe Gen 5 NVMe drives can push data at 10 GB/s, yet standard C++ file abstractions often leave them starving for data. Many developers think they need to abandon portability in favor of unmaintainable, OS-specific kernel bypasses to achieve the throughput necessary to saturate these drives. This session is for developers writing high-throughput, performance-critical applications who want to hit bare-metal speeds without sacrificing clean architecture, cross-platform support, or type safety.

Using a high-throughput cryptographic hashing engine as a concrete case study, this presentation demonstrates how to design a hardware-saturating data pipeline built entirely on the idioms of C++26. We will explore how the mathematical design of an algorithm - specifically BLAKE3's binary Merkle tree structure - can be mapped directly to wide SIMD vector lanes and concurrent CPU cores. We will walk through an execution model that completely bypasses the OS page cache, orchestrates memory without heap allocations on the hot path, and unifies OS kernel quirks in a portable way.

By the end of this presentation, you will learn how to replace rigid thread pools with lock-free, asynchronous execution graphs using Sender/Receiver paradigms (std::execution) and vectorization (std::simd). Crucially, we will focus on the build engineering required to make this work today. We will cover how to use advanced CMake tooling to safely compile multi-architecture vector binaries from a single source of truth, how to prevent LTO cross-contamination, and how to structure your pipeline today to seamlessly absorb upcoming C++ features in a world of trailing vendor toolchains.

This talk is the 2026 edition of our series that highlights low-latency, networking, parallelism, and concurrency proposals to the C++ Standards Committee, especially those discussed in the Kona 2025, Croydon 2026, and Brno 2026 meetings. This talk from the Concurrency TS2 Editors, DG and SG14/19 chair will describe the following features and show how they can be used. It will also give their motivation, background, and their place within the overall framework of C++ low latency, networking, parallelism and concurrency:

Atomic Compare and Hazard Pointers Reclamation Control

• We discuss a proposal for atomic compare operations that clarify programmer intent and simplify static analysis by avoiding the unnecessary leakage of atomic values. We also explore how these operations complement recent proposals to enhance the expressiveness of atomics, such as the use of tagged pointers.
• We examine techniques for controlling C++26 hazard pointer reclamation, demonstrating how to offload retirement overhead to asynchronous executors to ensure predictable thread latency. We show how this capability can prevent specific deadlock scenarios and assess whether such controllers should be standardized or remain user-space patterns.

Twenty-One Years Without Sockets, The History of Networking in C++ and What We Learned Along the Way

• Go has standard networking. Rust has standard networking. C++ has been trying since 2005. This talk tells the twenty-one-year story in seventeen minutes: the library that shipped but never standardized, the dependency that blocked it, the coroutine revolution that changed the assumptions, the technical discovery that explains why I/O doesn‚Äôt fit the three-channel model cleanly, and the bridge that lets both models win. Three decision points, three lessons, one live question: how should coroutines and senders coexist for C++29? No villains. Just the story and the engineering. Networking is now finally a C++29 priority, so said the Direction Group‚Äôs P5000.

Out-of-Thin-Air (OOTA) Values.

• The memory models for high-level languages, including C++, C, Rust, and even Java, have been prone to out-of-thin-air values. For example, given two atomic integers X and Y, both initially zero, if one thread does a relaxed assignment from X to Y and the other does a relaxed assignment from Y to X, the mathematical C++ memory model does not rule out the outcome where both X and Y have the value 42. However, both communication and computation take time, and so we have proven that OOTA values cannot happen on real-world production-quality computer systems. This result makes compiler-writers‚Äô lives easier, and also eases the jobs of those brave individuals pursuing the full mathematical OOTA problem by relieving them of the need to live within CPU and memory constraints of production-quality compilers.

Discussion

There are other features under discussion, but the features we will present seem close to approval, are particularly interesting, and/or are relatively non-controversial. We will show use cases for each and prognosticate their journeys to C++26 and beyond. This will help programmers in concurrency, lock-free programming, and low-latency applications understand how best to take advantage of each of these important facilities.

What makes an async workflow readable? Not just linear control flow — you also need to see where errors go, what each step depends on, and how failures compose. This talk takes a single production workflow — multiple async RPC calls with conditional branching, parallel fan-out, and partial-failure handling — and shows it implemented in three paradigms: callbacks with thread pools, a workflow orchestration graph over futures, and coroutines with std::expected. We evaluate each through four questions: where does the control flow live, the error flow, the coupling, and the migration risk?

Coroutines restore linear control flow, but without structured error composition, the workflow drowns in manual failure checks at every step, that is more error-handling code than business logic. Task

Sean Parent's "no raw pointers" guideline is often misunderstood as "avoid T* , use smart pointers instead", even though Sean explicitly included smart pointers in his definition of a raw pointer: "anything with implied ownership and reference semantics".

This talk presents a refinement of that guideline:

Pointers - smart or not - shall not appear in function signatures, neither as argument nor as return type.

The focus of this talk is how to implement classes as regular types while still supporting dynamic allocation, polymorphism, and sharing internally.

It shows how such value types can be implemented manually, without dedicated library support. It then follows the evolution of the language and library in gradually simplifying these abstractions: C++11 smart pointers ( unique_ptr and shared_ptr ), C++26 vocabulary types ( indirect and polymorphic ), as well as in-progress proposals ( copy_on_write and protocol ) are presented as tools to simplify writing safe abstractions, not as safe abstractions themselves.

Along the way, the talk revisits the Rules of 3/5/0, exception safety guidelines, const propagation, aliasing, and local reasoning.

The talk aims to make you stop passing pointers around.

Time handling in C++ looks simple — but it has some caveats. Between system_clock , steady_clock , high_resolution_clock , and a few new friends from C++20, it’s easy to pick the wrong one and end up with flaky tests, wrong timestamps, or confusing results.

This talk demystifies how time works in C++. We’ll explore what a "clock" really is, how std::chrono models it, and why not all clocks tick the same way. You'll learn when to use each standard clock, how to reason about monotonicity and precision, and how to build your own custom or fake clocks to make testing reliable.

By the end, you'll not only understand the difference between wall time and steady time — you'll know how to use them confidently in your production and test code.

For almost 30 years, Visual Studio has been a core part of the C++ developer's toolkit on Windows. This year, we're building on that foundation with investments across three themes: making the IDE faster and more responsive for large codebases, advancing compiler conformance and runtime performance, and integrating AI-powered workflows that help you debug, refactor, and optimize more effectively. Beyond the IDE, we'll show you how AI-powered command-line tools can become a natural part of your development process. This session combines demos and practical guidance so you can get the most out of these tools right away. Come with curiosity, leave with new techniques you can apply immediately.

Many codebases contain several spots of type punning, and unfortunately a whole lot of those are incorrect and undefined behavior. While many current versions of compilers seem to do the correct thing, they might no longer do that tomorrow. Safety considerations wants to reduce/eliminate UB.

It might be worthwhile to inspect your reinterpret_cast constructs, most probably they are wrong. In this talk we will inspect what is wrong about those, we will learn about alignment, strict aliasing, object lifetime. 3 areas which might flag a red card on our type punning constructions.

Luckily the language evolved and gave us more tools to do it correctly, things like memcpy, memmove, bit cast, start lifetime_as, launder. It does however remain a dark corner and a dangerous territory to wander in. Because let's face it, zero copy is something we love in C++, and those bytes that came from the network, really are an array of integers, array of coordinates, ... Compiler, trust me, I know what I am doing. Am I?

Zero-cost abstractions are a foundational idea in C++, promising expressive, high-level code without sacrificing performance. However, developers often encounter unexpected costs when using modern abstractions in practice, even when the code appears idiomatic and well-designed.

This talk explores the assumptions behind zero-cost abstractions and examines what happens when those assumptions no longer hold. Through concrete examples drawn from modern C++ — including ranges and views, type erasure, allocators, and other common abstractions — we will examine how factors such as optimizer visibility, inlining boundaries, allocation behavior, and runtime flexibility influence performance.

This talk treats abstraction as a powerful engineering tool, examining the limits of its zero-cost guarantees in real-world systems. We will look at how seemingly small design choices can introduce hidden costs, why those costs are often difficult to spot through inspection alone, and how to recover performance without abandoning good design or readability.

Attendees will leave with a clearer understanding of when abstractions are truly zero-cost, how to recognize situations where they are not, and how to make informed tradeoffs between expressiveness, flexibility, and performance in modern C++.

This talk takes you through the research and optimization of radix sort, culminating in its integration into libc++.

You will learn : common pitfalls of radix sort implementations (non-binary digits, dynamic memory allocation, fragile interfaces), how to design a strict and high-performance interface (fixed digit size, external buffer, projection to integers), and how to overcome radix sort's main drawback — its lack of naturalness — with two counter-based optimizations and a hybrid merge scheme.

The result : on arrays of 60 int32 elements (18 for int8), radix sort starts beating std::sort ; on large arrays, it's up to 10x faster. Floating-point types (float/double/float16_t) are also supported via IEEE 754 bit transformations (sign and exponent inversion for negative numbers).

The key takeaway : in modern libc++, for integers and floats, std::stable_sort on random data is noticeably faster than std::sort . Life has become better, but also more complicated — choose your sorting algorithm wisely.

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.

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?

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.

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.

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.