CppCon 2026

Building embedded systems wastes time on infrastructure instead of features. Before running application logic, developers lose hours bootstrapping init systems, wiring services, debugging startup failures, and fighting tooling never designed for constrained or early-boot environments. AEMBER is a developer-first PID1 (init system) that eliminates this overhead by providing a modern C++ runtime for process supervision, container orchestration, and service management - letting you focus on your application, not your plumbing.

This talk demonstrates how C++23 enables robust embedded systems without sacrificing performance. We'll explore std::expected for exception-free error handling, if consteval for compile-time optimization paths, and deducing this for zero-overhead policy classes. You'll see how monadic operations compose system calls into clean pipelines, and how modern C++ features build type-safe APIs for namespaces, cgroups, and process management.

Starting from main(), we'll trace AEMBER's architecture: how components compose, how errors propagate through std::expected chains, and how C++23 patterns enable embedded systems to be both safe and fast. We'll wrap up with a live demo showing AEMBER managing containers and services in real-time. You'll leave with concrete techniques for building maintainable embedded infrastructure using cutting-edge C++.

This session dives deep into the world of vulnerabilities from a C++ developer's perspective. Using a simple embedded device as the playground, where the memory model is stripped to the bare essentials, attendees will explore how classic attacks like buffer overflows can be used to hijack control flow, inject code, and manipulate the stack.

Everyone has heard the warnings about buffer overflows, use-after-free, memory corruption, and other infamous vulnerabilities lurking in low-level code. But many developers accept that these traps should be avoided without truly understanding how the exploits work. In this talk, attendees will see hands-on examples of how memory vulnerabilities arise, how they’re exploited, and why they’re dangerous.

But this session is not just about breaking things, it is about building them right. We will explore how modern C++ techniques like smart pointers, bounded containers, and RAII can prevent these issues altogether. By the end of the talk, developers will not only understand the risks but feel confident applying C++ best practices to write safer, more robust code.

Whether you are a systems programmer, embedded developer, or security-minded engineer, this session will deepen your understanding of C++, not just as a powerful language, but as a tool for writing secure, reliable software.

C++ runs the world’s systems, and with that comes a responsibility for safety and stability. Avoiding AI entirely gives up on incredible potential benefits, but using AI without guardrails poses significant risks to our critical systems. How does AI fit into this world? This talk examines effective and ineffective approaches to using AI in systems that cannot afford “slop.” We will explore several case studies where AI produced significant value in C++, and several where it did not. The pattern that emerges is consistent: AI thrives when it is orchestrating well-defined, deterministic components, translating between them intelligently without being trusted to reason correctly on its own. When AI is asked to be the system rather than connect the system, things fall apart.

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.

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?

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.