CppCon 2026

The architecture of legacy compilers presents limitations for modern software development. As codebases scale, developers face increased compilation times. While language complexity is often cited, key architectural bottlenecks include pointer-chasing across deeply nested ASTs (cache misses), single-threaded type resolution, and significant thread-lock contention (RwLock) during parallel semantic analysis. What happens when we discard the Abstract Syntax Tree entirely and apply strict Data-Oriented Design to the compiler itself?

In this session, we will explore the internal architecture of the Vx compiler frontend—a heterogeneous systems programming language to safely maximize utilization of available CPU cores. We will dissect how to translate complex, tree-like program semantics into flat, contiguous arrays of 256-bit bit-packed Global Identifiers (GIDs).

By stepping away from traditional recursive tree-walking and object-oriented compiler design, attendees will learn how to implement high-throughput parallel pipelines.

This talk is not just for language designers. The architectural patterns used to build the Vx compiler—flattening graphs into arrays, deferred identity, and lock-free synchronization boundaries—are directly applicable to any C++ developer building high-performance, multithreaded systems.

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++ 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.

Making native code fast is a team sport: efficient algorithms, high-performance libraries, memory-conscious design, and modern hardware all play a role. But the critical link between your code and the hardware it runs on is the optimizing compiler.

This talk explores new & improved compiler optimizations in Visual Studio 2026, and how these improve the performance of existing C++ code with minimal source changes. We will examine both architecture-independent optimizations (such as improved scalar replacement, vectorization, and loop transformations) and architecture-specific enhancements (such as AVX-512 and NEON specific optimizations). Along the way, we will connect high-level C++ constructs to the generated assembly and CPU behavior to build an intuition for how performance improvements are realized. While the talk discusses Visual Studio code generation & optimizations, the tools and analysis apply to all native platforms & compilers.

We will also introduce sample-based profile-guided optimizations (SPGO) which uses the runtime characteristics of your application to guide optimization decisions, WITHOUT requiring traditional instrumentation. You will learn how SPGO works, how to apply it in practice, and where it delivers measurable gains: typically in the 5-15% range across real world native codebases.

Attendees will leave with a practical understanding of how to reason about native code performance, and how to leverage SPGO to turbocharge the performance of their code.

AI agents are accelerating code generation at an unprecedented pace, yet C++ file is still compiled as a monolithic translation unit, meaning a many-core machine often cannot rebuild a template-heavy file much faster than a single core. Header-heavy designs, inline functions, and templates compound the problem: the same bodies are parsed repeatedly, and small edits can invalidate an entire translation unit.

This talk presents a compiler-agnostic technique for splitting translation units into smaller independently compilable units. Using libclang, the tool rewrites headers and sources into declaration-only interfaces plus generated .cpp fragments, backed by a shared preamble that can turn into a C++ module, precompiled header, cached serialized AST and a source-map. The fragments compile in parallel, then link into a binary functionally equivalent to the original monolithic build.

Expect benchmarks from major codebases covering compile-time, link-time, and run-time performance; live demos of fast incremental updates that avoid reprocessing unchanged code as well as an analysis of the resulting binaries layout.

Tooling Track sessions are sponsored by Optiver.

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!

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.