CppCon 2026

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.