CppCon 2026

CUDA Tile C++ is a novel C++ DSL and compiler that automatically parallelizes array operations across GPU threads while presenting a single logical thread to the programmer. In CUDA Tile C++, parallelism is expressed through SIMD-style operations on arrays of data called "tiles" while memory accesses are written using structured memory abstractions. The compiler analyzes the tile and memory operations to generate an equivalent multi-threaded program that leverages the advanced hardware capabilities of modern GPUs. This allows the user to write simple programs that exploit GPU parallelism without needing to manage low level hardware concurrency.

As GPU architectures evolve to meet the demands of high performance computing, the traditional multi-threaded GPU programming model becomes increasingly unwieldy. To achieve optimal performance, the GPU programmer must manage a growing variety of hardware features including shared memory, Tensor Memory Accelerators, and Tensor Cores. Traditional CUDA code is deeply coupled to the underlying hardware resulting in complex and non-portable algorithms. The CUDA Tile C++ compiler removes the need for coordinating these low level hardware details, freeing the user to reason about their algorithm rather than asynchronous code.

The tile programming model introduces three key abstractions:

• cuda::tiles::tile - a multi-dimensional array with value semantics whose operations are parallelized across the GPU
• cuda::tiles::tensor_span - a view into a multi-dimensional in-memory array with an interface similar to std::mdspan
• Tile Views - adapters that present a uniform "chunking" of a tensor_span which gives the compiler visibility into memory access patterns

In this talk, we will explore how these abstractions allow NVIDIA's Tile C++ compiler to schedule the program across hardware threads all while preserving the illusion of a single-threaded abstract machine to the user.

C++23 is the latest evolution in modern C++ programming that is now fully supported by the latest versions of GCC, Clang, and Visual C++.

As the first release after introducing several new key features with C++20, which can be seen as the beginning of a new release cycle, it contains both significant extensions and improvement of various features introduced with C++20 and a couple of new language and library features.

In my new book "C++23 - The Complete Guide", I cover all aspects of tis release.

This session gives you the opportunity to talk with me about C++23 and discuss various aspects of in in general or a bit in detail.

In the C++ world, it is often assumed that proper object lifetime management ensures a memory footprint that scales with an application’s actual needs. However, long-running systems are frequently sabotaged by heap pinning: a phenomenon in which Resident Set Size (RSS) refuses to shrink even after significant deallocations. This results in a critical, 'invisible' overhead that defies standard leak-detection tools and can lead to system thrashing and even Out Of Memory (OOM) kills.

Heap pinning occurs when long-lived allocations are interleaved with transient ones, creating a structural barrier that prevents the underlying allocator from releasing memory back to the system. A single persistent allocation can 'pin' an entire block of physical memory, forcing the OS to keep it mapped even if the surrounding space is empty. Consequently, the process footprint reflects historical peak usage rather than the current live state.

In this talk, we will bridge the disconnect between C++ deallocations and physical memory reclamation. You will learn to use allocator-aware objects and std::pmr resources to eliminate pinning by strategically segregating allocations based on their expected lifetimes. We will also demonstrate how to diagnose these 'ghost' overheads when traditional heap profilers fall short. You’ll leave the session equipped to identify and resolve these fragmentation traps, ensuring your application’s memory footprint finally stays proportional to its actual state.

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.

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.

Tooling Track sessions are sponsored by Optiver.