CppCon 2026

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.

To write the best C++ application code, you must think like a library author. This talk reframes application development as a form of library design, where every component is a potential asset for future maintenance and extension.

We'll survey the C++ language features that empower library authors to create powerful, flexible, and safe abstractions. From there, we'll distill the 'library author mindset.’ You will leave with concrete principles and techniques to make your application code more modular, maintainable, composable, reusable, testable, and ultimately, more valuable.

As legacy C++ codebases evolve to meet new requirements, fix architectural issues, and address performance bottlenecks, refactoring becomes inevitable — but full rewrites are risky, costly, and rarely practical. This talk explores how modern C++ features — especially functional programming techniques and type erasure — can be used to refactor and extend legacy systems. We will present a concrete, low-risk, and measurable four-step technical framework for incremental modernization, by leveraging pure functions, discriminated union types, and type-erased callables to achieve safer, more flexible code with compile-time guarantees, even in traditionally object-oriented codebases.

The core of the talk will walk through the entire process on a concrete code example, illustrating (1) how to isolate existing logic, (2) define safer data models using immutable types, (3) deploy type erasure to create a robust, non-disruptive adapter boundary between old and new code, and (4) measurably execute the migration with safe testing practices. We will also share lessons learned from real-world experience and conclude by showing how these foundational patterns can be extended into future-thinking designs, leveraging examples with accepted C++26 features. Every step is grounded in real production constraints and trade-offs, and the techniques transfer directly to any domain where full rewrites are not an option. Attendees will walk away equipped with practical strategies to incrementally refactor your legacy systems without sacrificing stability or velocity.

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.

Every mature codebase carries history and technical debt. The challenge is modernizing without stopping the world or introducing big re-write failure risks.

In this talk, we’ll explore how to modernize legacy C++ codebases incrementally using a mix of deterministic code transformations and AI-assisted refactoring .

After delving into some of the common problems with legacy modernization, we'll start tackling the simple "boring" stuff that deliver huge leverage of changes via clang tooling . These represent repeatable, deterministic reviewable upgrades that can be automated and applied at scale.

Then we can look at more difficult transformations that can be AI assisted with more aggressive transformations including API improvements and how to prevent it going off the rails. This will be backed by Compiler diagnostics, static analysis and testing to keep changes maintainable and correct .

The goal is not to replace engineering judgment, but to accelerate it: turning modernization into a continuous, low-risk workflow instead of a disruptive project.

Attendees will leave with a repeatable playbook for modernizing legacy codebases incrementally, safely, and at scale—using the right tool for each class of change

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.