CppCon 2026

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.

C++ is used in many fields. One that sticks out is the embedded domain. You're often working with tight constraints. Writing software is challenging and fun at the same time.

What has C++ done to support this field? What new options do you have to avoid undefined behavior and write more efficient and robust code?

In this talk, I will present various library elements as well as language improvements that make writing embedded software better.

We'll look at real-world tasks like turning raw byte blobs into usable data structures, aka type punning, of course, without triggering undefined behavior. C++23 supports you in a new way with std::start_lifetime_as .

Transferring data via a network comes with its challenges. You have to care about the byte order. Oh, and how can you make sure that there are no padding bytes included? Well, I have an answer for you.

And then there is a brand-new feature in C++26: static reflection. I will present examples of how and where reflection in C++ eases embedded development.

By the end of this talk, you know the most important improvements in C++ for embedded or similar environments.

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.

Working with C++ code can be difficult, and it's made even more difficult when the code isn't your own. Everyone agrees that documentation is necessary when sharing a library. But, as a user of a library, the documentation may not help when you want to know the current state of your program. If you're a veteran C++ programmer then you may easily find your way around memory readouts, putting print statements in exactly the right spots, or reading "between the lines" of the documentation. Some of us are not very experienced, or we aren't able to recompile the code with print statements, or the documentation may not help with the problem.

Hopefully, the author had written a GDB extension to pretty-print their data types. But odds are, they didn't. As library writers, or as people writing classes for others to use and reuse, we can and should be writing debugger visualizers. We can empower our users by lowering the barrier to using the library successfully. Let's make our libraries more accessible. Software is about more than just the source code.

This talk will help you make the most of GDB extensions. After briefly discussing how to get started with GDB assuming zero prior knowledge, we will discuss how to write a GDB pretty-printer, how to set up your system to use the pretty-printer, how to embed it into your compiled binary, and how to distribute it with auto-loading scripts. By the end of the talk, the user will not only know the basics of writing a simple "to_string()", but will also understand how to effectively display containers and how to implement custom debugger-side user-facing extension methods. Let's get excited about debuggers!