CppCon 2026

Much of the public criticism of C++ safety comes from vulnerabilities rooted in C patterns: raw pointer arithmetic, unchecked buffer indices, manual memory management. Modern C++ offers real answers to those problems through RAII, smart pointers, containers, and type-safe abstractions. But C++ also has its own distinct safety issues that have nothing to do with its heritage. Temporary lifetime rules that silently create dangling references. Iterator invalidation semantics that differ across containers in ways even experienced developers get wrong. Smart pointer ownership pitfalls that RAII cannot prevent. Coroutine frames that outlive their captured locals. Implicit conversions that turn a safe string into a dangling view between one line and the next. These are purely C++ problems. They compile cleanly, look correct in code review, and ship to production.

A survey of public CVE reports and security-fix commits across prominent open-source C++ projects shows the same patterns recurring again and again. This talk walks through those patterns, in code that looks correct in review, compiles cleanly, and then breaks at runtime. The session is aimed at intermediate-to-experienced C++ developers who already know modern C++ but want a working catalog of the subtle patterns that ship past typical code review.

Recognizing these patterns has long been the domain of library authors and security researchers. This talk distills a catalog from real-world fixes for everyone else: not a prescriptive standard like the Core Guidelines, but a pattern-recognition toolkit any C++ developer can apply in their next code review. The session also makes the case for expanding the community-level safety conversation to give these C++-unique patterns the same attention as the C-heritage debates.

Air-gapped systems used to be protected by what they could not reach. That assumption breaks when telemetry, sensor data, and diagnostic output leave the system and AI model-influenced behavior comes back in, even without a network connection.

This talk examines the C++ engineering decisions that determine whether that data exchange is safe or silently dangerous. The problems are C++-specific and subtle: struct layout and padding that corrupt data silently across serialization boundaries; undefined behavior in type-punned casts that passes tests but breaks under a different compiler or optimization level; ownership and lifetime assumptions that hold inside the system but become dangling references once data crosses a trust boundary; allocator and exception constraints in no-exception embedded environments that make standard validation patterns unavailable.

We will look at how C++ systems in industrial, embedded, and safety-critical environments can export logs, telemetry, and traces into AI pipelines without creating feedback loops that affect production behavior in unverified ways. The engineering controls are concrete: typed serialization boundaries that make layout assumptions explicit, schema validation that survives ABI differences between host and edge, provenance tracking built into ownership types, deterministic guardrails around probabilistic inference outputs, and fail-safe fallbacks that don't rely on the model being correct.

Attendees will leave with a design approach for integrating AI-adjacent workflows into high-integrity C++ systems. One that treats the data boundary as a first-class security surface, not an afterthought.

Many codebases contain several spots of type punning, and unfortunately a whole lot of those are incorrect and undefined behavior. While many current versions of compilers seem to do the correct thing, they might no longer do that tomorrow. Safety considerations wants to reduce/eliminate UB.

It might be worthwhile to inspect your reinterpret_cast constructs, most probably they are wrong. In this talk we will inspect what is wrong about those, we will learn about alignment, strict aliasing, object lifetime. 3 areas which might flag a red card on our type punning constructions.

Luckily the language evolved and gave us more tools to do it correctly, things like memcpy, memmove, bit cast, start lifetime_as, launder. It does however remain a dark corner and a dangerous territory to wander in. Because let's face it, zero copy is something we love in C++, and those bytes that came from the network, really are an array of integers, array of coordinates, ... Compiler, trust me, I know what I am doing. Am I?

C++20 coroutines are a game-changer for writing asynchronous code and generators, but they come with a steep learning curve. This talk is designed to simplify the concept and make coroutines more approachable.

We’ll focus on co_await — how it works, what it does under the hood, and why it's useful. If you’ve been curious about coroutines but found the resources confusing, this talk is for you.

Benchmarks shouldn't live in a different world from tests. Most C++ projects already use Google Test, but the moment performance enters the picture, developers reach for separate tools, separate workflows, and ad-hoc timing loops that don't survive contact with CI. This talk argues for a different default: treat performance measurements as first-class tests. They are written in the same harness, run in the same suite, and fail the same builds.

Using a real C++23 framework built on top of Google Test, the session shows what that looks like in practice. Semantic macros distinguish throughput, latency, and contention tests; built-in statistical analysis tracks medians, percentiles, and coefficient of variation. Adaptive thresholds scale with payload size, so tiny operations and multi-megabyte workloads aren't held to the same stability expectations.

Once benchmarking lives inside the test framework, the rest of the performance toolchain follows. Five CPU profiler backends drop in behind a single --profile flag: perf, gperftools, bpftrace, RAPL, and callgrind. Attaching a memory profile to a test prints bandwidth, efficiency, and a CPU-bound or memory-bound classification with no extra code. The same harness extends to CUDA through a fluent kernel builder that captures launch configuration, achieved occupancy, transfer overhead, multi-GPU scaling efficiency, and thermal throttling. Nsight Compute drops in through the same --profile flag.

The payoff is CI integration that's nearly automatic. A companion CLI tool compares baseline and candidate runs, applies statistical thresholds, posts markdown reports on pull requests, and fails the build on regressions. The result is a single workflow for performance verification that scales from a developer's laptop to a CI runner to a Jetson on a workbench, across hardware ranging from x86 to ARM to RISC-V.

Years ago while working on a service that would be deployed in Kubernetes, we decided to use the simplest possible TCP based healthcheck. Not because TCP was the right choice, but because implementing a simple HTTP endpoint was more code than it was worth. For our Go services the equivalent HTTP endpoint was only a couple of lines. In fact, we eventually ended up replacing our TCP endpoint with a small Go wrapper around our C++ service.

The Go standard library has done a great job at designing a very ergonomic HTTP library. C++ now has all the right building blocks to express the same design concepts: coroutines, concepts, std::expected, std::jthread. The question is, do these patterns transfer from Go to C++? How do we evaluate the effectiveness of the resulting design?

In this talk I will present a small HTTP library inspired by Go's net/http, built with the tools available in C++23. To evaluate the resulting design I will draw on ideas from Felienne Hermans' The Programmer's Brain and the principle, from Structure and Interpretation of Computer Programs, that API design is language design.

Along the way we'll see which patterns transfer cleanly, which need translation, and why telling the difference is a skill worth developing even if you only work with C++.