CppCon 2026

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.

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.

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.

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.