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.

Every Boost library that graduated to the C++ Standard became invisible. shared_ptr doesn't say "Boost" anywhere in . Boost's greatest successes carry no signature — and that invisibility is killing recruitment. This talk is not a status report. It is an answer to the question: why would I give my best work to a project that erases my name?

We begin with the people. Peter Dimov. Beman Dawes. Howard Hinnant. Marshall Clow. These engineers didn't just write libraries — they defined what production-quality C++ means. We will say their names, show their faces, and then ask the only question that matters for Boost's future: who replaces them? Every technical detail in this talk serves that question.

The answer starts with the peer review process — not as a quality gate, but as an apprenticeship. Boost review doesn't just catch bugs; it forges people. It is the mechanism by which a competent developer becomes a Dimov-class designer, and we will show how that pipeline works today.

Then the technical core. Boost.Unordered's unordered flat map — not as a benchmark, but as a character study. Joaquín López Muñoz sat down, studied SIMD probing, and built something faster than a team at Google. We won't just show a bar chart; we'll show the design decisions — the one that made it fast and the one that almost kept it from shipping. Boost.Intrusive — presented as a magic trick before an explanation. One object. Three containers. Zero allocations. We'll let the audience sit in "wait, that can't work" for ten seconds before we reveal the mechanism. Boost.Decimal — IEEE 754 decimal floating-point that feels like a native type, with portable performance rivaling GCC's non-portable _Decimal extensions. We will also cover Boost.JSON, Boost.URL, Boost.Scope, Boost.Cobalt, and the design thinking behind each.

Networking gets its own act. Beast, Corosio, Capy — presented as a list, they're alphabet soup. Presented as what they are, they become a statement of intent: Boost is building the networking layer the committee has been unable to standardize for fifteen years, and we believe we can ship it. We will show how buffer sequences, stream concepts, and type-erased I/O deliver ABI-stable networking compiled once against an abstract transport, and how this connects to active WG21 proposals for C++29.

We close not with a mailing list URL but with a name. One person — a contributor who submitted their first Boost PR this year, went through review, and is now preparing a library for formal consideration. A person is a door; a URL is a wall. The thesis of this talk is not "Boost is alive." The thesis is that Boost is where you become the engineer you want to be — and every section, from the review process to the mentorship lineage to the fact that one person can build the fastest hash map in the industry, is proof.

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.

For almost 30 years, Visual Studio has been a core part of the C++ developer's toolkit on Windows. This year, we're building on that foundation with investments across three themes: making the IDE faster and more responsive for large codebases, advancing compiler conformance and runtime performance, and integrating AI-powered workflows that help you debug, refactor, and optimize more effectively. Beyond the IDE, we'll show you how AI-powered command-line tools can become a natural part of your development process. This session combines demos and practical guidance so you can get the most out of these tools right away. Come with curiosity, leave with new techniques you can apply immediately.

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 modules are finally usable end to end, from your own modules to 'import std;' The functional build-system support with real diagnostics. This talk teaches modules the way #include was once taught: with small files, a build, and concrete use cases. Modules stopped being experimental somewhere around 2025. This session builds the mental model from scratch: what a primary module interface unit is, how partitions and implementation units fit together, and, crucially, how import differs from #include in ways that matter day to day. It uses a small library, exposes it as a module, splits it across partitions, consumes import std; and observes the compile-time effect. Then it answers the questions every team hits in week one: how modules interact with macros, with templates in headers, with header-only dependencies, and with a mixed codebase that can't convert everything at once. The examples will be using CMake, clang and recent gcc. You will leave able to structure a small library as a module, explain why a macro didn't cross a module boundary, and plan an incremental adoption that doesn't require converting the whole tree.

Zero-cost abstractions are a foundational idea in C++, promising expressive, high-level code without sacrificing performance. However, developers often encounter unexpected costs when using modern abstractions in practice, even when the code appears idiomatic and well-designed.

This talk explores the assumptions behind zero-cost abstractions and examines what happens when those assumptions no longer hold. Through concrete examples drawn from modern C++ — including ranges and views, type erasure, allocators, and other common abstractions — we will examine how factors such as optimizer visibility, inlining boundaries, allocation behavior, and runtime flexibility influence performance.

This talk treats abstraction as a powerful engineering tool, examining the limits of its zero-cost guarantees in real-world systems. We will look at how seemingly small design choices can introduce hidden costs, why those costs are often difficult to spot through inspection alone, and how to recover performance without abandoning good design or readability.

Attendees will leave with a clearer understanding of when abstractions are truly zero-cost, how to recognize situations where they are not, and how to make informed tradeoffs between expressiveness, flexibility, and performance in modern C++.

Notifiers are a critical synchronization primitive in task-parallel programming systems such as Intel TBB and Taskflow, responsible for efficiently sleeping and waking worker threads as tasks become unavailable and available over and over again, directly impacting scheduler throughput and latency. Correctness here is non-negotiable: a single missed wakeup can significantly hamper the performance of an entire program. Yet writing strong unit tests for notifiers is notoriously difficult, because the bugs they target, lost wakeups, spurious wakes, race conditions, are timing-dependent, non-deterministic, and often only surface under specific thread interleavings that are hard to force reliably.

The problem is compounded in practice. Notifier implementations evolve constantly: small algorithmic tweaks, memory ordering changes, and refactors across systems demand a fresh round of carefully constructed tests. This is tedious, expertise-heavy work that takes a lot of time and engineering effort. In this talk, we explore using Large Language Models (LLMs) to automate the generation of the unit tests for notifiers. Specifically, we will demonstrate how LLM-generated tests, guided by proper prompts can systematically stress the two-phase wait protocol across Notifiers in Taskflow. We will show this in a widely used Notifier implemented in Taskflow. We are able to find an undiscovered bug that has been existing in the project.

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.