Software development has now shifted decisively to a distributed, asynchronous paradigm, in which engineers must manage code that may be executing on parallel threads, or on a different machine. Many mainstream programming languages have adapted themselves to this new world. For example, JavaScript has promises and async/await, Python has asyncio, Rust offers zero-cost async/await with compile-time safety, and Go built goroutines and channels as first-class primitives.
C++ developers face the same challenge but have been left without a standard solution. As a result, much production code remains stuck in “callback hell,” where control flow is inverted, error handling is duplicated at every level, and common patterns like "run A and B in parallel, and then combine results" must be hand-rolled every time.
This is not simply a matter of bolting async/await onto C++. Deterministic destruction, zero-overhead abstraction, and precise control over memory and lifetimes, these very properties making C++ powerful dictate that an async framework cannot rely on a garbage collector or managed runtime to paper over complexity. It must earn its place by working with the language's ownership model, not around it.
std::execution is C++’s answer to this problem. Introduced as part of C++ 26, it solves this through composable senders: lazy, type-safe descriptions of work that can be chained, branched, and parallelized before being submitted to an execution context. Like Swift's structured concurrency, std::execution enforces structured lifetimes so that async work cannot silently outlive its scope.
This talk aims to provide application developers with an introduction to the current proposal and give them a grounding in the fundamentals that can be applied in real-world applications. We will walk through several worked examples: from simple chains to parallel fan-out with error propagation, showing side-by-side comparisons with callback-based equivalents to make the advantages more concrete and relatable.
This talk assumes no knowledge of the std::execution framework and no expertise in async programming, though practical, real-world experience will certainly help ground the examples. Attendees will leave with a working understanding of the sender/receiver model, practical patterns they can use, and a clear picture of what structured concurrency means for C++.
Alistair Fisher is an Engineering Team Lead at Bloomberg. He works in the Multi-Asset Risk System (MARS) Pricing group in London, where he is focused on building scalable and reliable components for portfolio pricing and risk analysis. He is interested in the use of functional programming... Read More →
Floating point has a reputation for betrayal. Change the thread count, vector width, compiler flags, reduction tree, or target architecture, and the low bits can move. Parallel algorithms make this worse: the standard often specifies the operation, but not the numerical expression whose result must be reproduced. This talk asks a provocative question: what if reproducible numerics did not have to be slow?
We will show reproducible, deterministic implementations of reduce and scan that exhibit better error behavior on hostile floating-point workloads and can match or beat conventional standard-library implementations on realistic workloads. The trick is not to freeze the execution schedule. It is to specify the expression being computed, then let the implementation use SIMD, threading, blocking, tiling, and platform-specific strategies to compute that expression efficiently.
The key idea, developed through C++ standardization work such as P4016R0 and P4229R0, is reproducibility by reproducing the computation. Instead of asking the implementation to promise a particular schedule, we give the calculation a named expression. Once that expression is chosen, changing the thread count, vector width, chunking, or blocking strategy does not silently change the answer.
A reproducible scan makes this harder than reduce because it does not expose only one final value. It exposes every prefix. A reproducible final sum is not enough if the intermediate results still drift. We will show how expression and observation contracts make those prefixes reproducible without forcing the computation back into a slow sequential order.
Then we go below the algorithm layer, to the places where bits usually escape: FMA contraction, denormals, floating-point environment choices, math-library approximations, and vectorized transcendental functions. The goal is not to get the same answer by turning off the hardware. We will show reproducible vectorized primitives, including transcendental functions, running at speeds comparable to established vector math libraries while preserving a cross-platform numerical contract.
Finally, we put the whole stack under stress: a heterogeneous numerical pipeline across x86-64, Apple Silicon, and CUDA. The data is deliberately hostile, with high cancellation rates and fragile intermediate states. The aim is not to pass friendly benchmark cases, but to reproduce the specified computation, including the same intermediate failures, not just the same final answer, bit for bit, across CPUs, GPUs, and toolchains.
Andrew Drakeford A Physics PhD who started developing C++ applications in the early 90s at British Telecom labs. For the last two decades, he has worked in finance developing efficient calculation libraries and trading systems in C++. His current focus is on making quant libraries... Read More →
Getting a project approved, or killed, often has less to do with technical merit than with who actually holds the keys and what they need to hear. This talk draws on real case studies from library design fights, cross-functional infrastructure rewrites, and a couple of notable failures to show practical techniques: how to find the real decision-maker, how to break expert deadlock with a position paper, and how to build toward an audacious goal through incremental wins and a well timed crisis.
Some of the most expensive C++ bugs are not caused by obscure language features. Instead, they emerge from code that looks reasonable: shared ownership that quietly extends lifetimes, singletons that become invisible dependencies, and performance-driven decisions that harden into architecture.
This talk examines these common design-level failure patterns in large-scale C++ systems. We cover three concrete design shifts:
Lifetimes: Shifting from shared ownership to explicit lifetime boundaries. Coupling: Shifting from implicit global coupling to injected dependencies. Interfaces: Replacing permissive APIs with constrained interfaces using std::span, std::optional, std::variant, and strong types.
Each shift is presented with the failure pattern it addresses, the solution, and the design rule it yields. Attendees will leave with practical heuristics for designing systems that are easier to reason about, test, and evolve: all grounded in real-world failures and the redesigns that fixed them.
Divya Chandrasekar is an Engineering Leader at Bloomberg, where she leads FXGO Orders, a trading platform within FXGO. She holds a master’s degree in Computer Engineering from the University of Florida and has held multiple engineering roles at Bloomberg. With a strong technical... Read More →
Devpriya Dave is a software engineer on the FX Options team at Bloomberg. While at Georgia Tech obtaining her master's degree, she helped design and build the system behind Georgia Tech's Machine Learning for Trading online course. She is passionate about STEM mentorship and is always... Read More →
In the C++ ecosystem, we have powerful tools for understanding our programs before, during, and after they run. But compiler warnings, clang-tidy, cppcheck, sanitizers, debuggers, profilers, and coverage tools all answer different questions, and using them well starts with knowing which question you are asking.
This talk introduces code analysis from first principles. We will compare static techniques such as compiler diagnostics, linting, and include analysis with runtime techniques such as sanitizers, coverage instrumentation, and profiling. We will also briefly connect these tools to the direction of modern C++, including C++26 contracts and standard library hardening, where some assumptions that used to live only in comments, documentation, or debug modes become part of the program's checkable structure. Through small C++ examples, we will see what each category of tool can reveal, what it cannot prove, and how the tools complement each other.
Attendees will leave with a practical mental model for choosing the right analysis tool for the task at hand, interpreting its output, introducing analysis into an existing C++ codebase, and writing code that is easier for both humans and tools to understand.
Alexsandro Thomas is a Senior Software Engineer at Zivid AS specializing in C++ API development, build systems, and developer tooling. His interests include GPGPU, compiler technology, and low-level programming. In his free time he enjoys studying programming and natural languages... Read More →
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.
I've been working on LLVM since 2012. I've contributed to modern compiler optimizations like GVNHoist, Hot Cold Splitting, Hexagon specific optimizations, clang static analyzer, libcxx, libstdc++, and graphite framework of gcc.
Building on the recent work of improving the quality of Sea of Thieves' codebase by upgrading from C++14 to C++20, this talk will focus on the work that has went into enabling warnings as errors on the game, and more.
Rare will discuss the motivations behind wanting to crank up the warning level, and to flick the "warnings as errors" switch after 10 years of development in their multi-million line Unreal Engine code base.
What were the challenges? How much effort did it take? Was it worth it? Did we find any bugs? Did we stop at just "/W4 /WX"? What warnings did we find the most useful? What warnings were deemed unhelpful? All of these questions and probably more will be answered throughout this session.
Keith Stockdale is a Northern Irish senior software engineer who has been working on the Engine and Rendering teams at Rare Ltd for the last 8 years working on Sea of Thieves. At Rare, Keith's main areas of focus are involved in maintaining and creating general purpose simulations... Read More →
Memory leaks are very hard to treat. We have reliable tools like valgrind or AddressSanitizer to tell us whether or not an application has leaked memory, but current tools cannot tell us where the leak happens (they can tell us where the allocation happened,which is not the same).
I show that it is possible to run an analysis that is equivalent to running a garbage detection pass after every instruction and use that to find the actual cause of memory leaks in open source applications.
Using a garbage detection algorithm on record-and-replay recording, one can overcome the most obvious obstacle: stopping a program a program after every instruction or running garbage detection algorithms is very slow, but we can effectively run a bisection search on the recorded timeline to avoid having to evaluate after every instruction.
The goal is attribution to source code. Are we limited to reporting the instruction that overwrites the last reference to allocated memory or can we actually diagnose a specific error for a concrete function?
Henning is a C++ software developer with ten years of experience ranging from small start-ups to large enterprises. He has PhD in Mathematics from the University from Kaiserslautern and is currently working on new debugging tools for C++.
Was generating lines of code / upping the commit count the major impediment to delivering stable production ready software?
AI-assisted development has lowered the barrier to churn out code, helped engineers move faster in unfamiliar codebases, and made legacy systems easier to approach. however increased code output does not automatically mean better delivery of more reliable code.
In this talk, we will look at some of the emerging problems that are now becoming evident with AI ***amplifying existing weaknesses** such as code duplication, larger pull requests and the temptation to accept plausible generated changes without sufficient scrutiny . AI does not remove the need for engineering judgment. It removes the friction that used to slow down code creation
We will explore practical lines of defense to effectively reinforce long-term codebase health including stronger pull request descriptions, shared reviewer responsibility, review checklists, and metrics
The goal is not to reject AI. The goal is to ensure that AI improves engineering delivery rather than accelerating technical debt.
Pete Muldoon has been using C++ since 1991. Pete has worked in Ireland, England and the USA and is currently employed by Bloomberg. A consultant for over 20 years prior to joining Bloomberg, Peter has worked on a broad range of projects and code bases in a large number of companies... Read More →
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++.
Arian Ajdari is a Software Engineer working on cutting-edge applications in the field of smart home appliances. His daily work includes discussions with clients, gathering requirements, building use-cases and implementing different solutions using C++. Arian possesses a deep understanding... Read More →
Modern coding agents are incredible, but they still struggle with the kind of large, unstructured codebases that are common in C++. There are several techniques and tools that can make them perform much better. Here we show examples and demos of how to get your agent to work better with complex code. The focus is on providing an overview on current techniques and how we’ve found they work best. - Skills, memory and MCP - these have all been hyped hard, we’ll sort through where they are actually useful. - All agents (Claude, Copilot, Codex, Gemini) support these - some better than others. - What a skill is and what it isn’t - How to use persistent memory - Why MCP servers are still needed (but not always) - Context engineering. - Context management keeps changing - we’ve got autocompaction and 1M token windows now, why should we care anymore? - When to “manage” your agent’s context window and when it’s a bad idea - How to understand where context is being spent. - How and why to use subagents - these are almost always available but the capabilities in different frontends are exposed in different ways. - Spec Oriented Development: buzzword, euphemism for vibe coding or the future of programming? - What is it? - What tools exist? Covering options such as SpecKit, Kiro, etc. - Working in parallel with agent teams! - How to get started without having to learn anything (almost)! - Runtime context. - How to give your agent the best possible feedback path so you can stop micromanaging it and leave it to complete longer, more complex tasks. - Techniques including testing, CI integration and recording-based technology
Greg is co-founder and CEO at Undo. He is a programmer at heart, but likes to keep one foot in the software world and one in the business world. Greg finds it particularly rewarding to turn innovative software technology into a real business. Greg has over 25 years' experience in... Read More →
I went through Cambridge University, UK and got drawn into the local startup ecosystem. I've been at Undo.io building time travel debuggers for Linux C++ developers for the past 11 years, eventually landing in my current role as CTO.
Right now I'm cramming AI-related knowledge i... Read More →
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.
Jason is host of the YouTube channel C++Weekly, co-host emeritus of the podcast CppCast, author of C++ Best Practices, and author of the first casual puzzle books designed to teach C++ fundamentals while having fun!
In many languages, you can mock almost anything. Python has unittest.mock, Java has Mockito and PowerMock, and C# has Moq. In C++, you can usually mock only what was designed to be mockable — and little else. Want to mock a free function? Wrap it in an interface. A static method? Refactor to a template. A non-virtual member? Redesign the class hierarchy. The cost is real: developers either shape production code around testing-tool constraints instead of domain needs, or they simply leave hard-to-mock code untested.
This talk introduces [LibraryName], a new C++ mocking library we developed (and plan to publish soon as open source) that can mock almost any C++ callable — free functions, static methods, non-virtual members, private members, templates, lambdas, and even extern "C" routines — without modifying the code under test. Developed and battle-tested at [CompanyName] for three years across a very large C++/C codebase, it aims to deliver a first-class testing experience for C++. Under the hood it uses runtime binary patching — replacing function prologues with redirections at test time, restoring them on scope exit — all surfaced through familiar Google Mock syntax.
We'll show [LibraryName] in action, walk through the patching mechanism, and share how to get started -- you'll walk away ready to test almost any function, regardless of how it was designed. Strong test coverage has always been essential, and AI-assisted code generation only increases the need for reliable testing backpressure. C++ deserves mocking tooling that matches.
Ilya Ermakov graduated from Vanderbilt University with a major in Computer Science. Since graduating, Ilya has worked at Bloomberg where he is now a Software Engineer working on Distributed Systems and C++ tooling.
Brian Rudo-Hutt is a Senior Software Engineer at Bloomberg and organizes engineering-wide initiatives to improve testing, safety, and software maturity. Brian holds Computer Science and Electrical and Computer Engineering degrees from Cornell University and lives with his family in... Read More →
Native C++ types often become the format for bytes that cross a boundary: shared-memory IPC, plugin interfaces, persistent storage, or software built for more than one ABI. At that point the type is no longer just an implementation detail; it is part of a binary contract. trivially_copyable , sizeof , and code review help, but they do not answer the two questions that matter: may this type be transported as bytes at all, and do all supported ABIs give it the same object representation?
C++26 reflection can derive that evidence from the type itself. The technique builds a compile-time layout signature from ordinary C++ types, without IDL, generated stubs, or runtime inspection. The signature records the representation facts needed for byte transfer: architecture and endianness, leaf type tokens, sizes, alignments, absolute offsets, bit-fields, and pointer-like markers. It deliberately leaves out field names and source-level meaning.
With those signatures in hand, the build can enforce a gate for memcpy-style transfer. You name the boundary types and supported ABIs. Each target exports signatures, and a verification build permits direct byte transfer only when the type is byte-copy safe and the signature matches across the set. We'll walk through the workflow with static_assert checks and CI diagnostics: a fixed-width type that passes, a pointer-containing type rejected by admission, and a platform-divergent type rejected by signature comparison. The claim is intentionally narrow: representation compatibility, not semantic compatibility or schema evolution.
Fanchen Su is a game research & development expert and team leader. He has over 20 years of experience in designing, writing, and maintaining C++ code. His main areas of interest and expertise are modern C++, code performance, low latency, and maintainability. He graduated from Wuhan... Read More →
Practical HPC — Forcing the Compiler's Hand with Modern C++
Achieving near-peak FLOPs on modern CPUs requires exploiting SIMD, register files, and cache hierarchies — yet the levers that matter most (loop unrolling, vectorization width, tile sizes, register tiling) are largely outside the programmer's direct control. Autovectorization is fragile, #pragma unroll is advisory and non-portable, and the information the compiler needs most — loop bounds, problem shapes, working-set sizes — is typically only available at runtime. The result is a familiar gap between theoretical peak and delivered performance, bridged in practice only by hand-written intrinsics or inline assembly, fragile macro forests, or external code generators that sacrifice maintainability and type safety.
Modern C++ is, sometimes surprisingly, an excellent language for closing that gap without leaving the host language. We walk through the concrete features that make this possible and how to use them in practice — templates and constexpr to promote runtime values into compile-time constants, if constexpr and parameter packs for shape-specialized kernels, generic and template lambdas for loop bodies that are unrolled and inlined by construction, and concepts to turn silent performance cliffs into compile-time errors. Together, these give the programmer precise control over what the compiler emits: compile-time dispatch that specializes kernels per shape and target, guaranteed static unrolling that unlocks ILP and register tiling without relying on optimizer heuristics, and hardware-aware specialization parameterized on register count, SIMD width, and cache sizes.
Looking forward, C++26 and static reflection push this approach considerably further, turning today's disciplined metaprogramming into something closer to first-class, in-language code generation — and squarely aligning the language with the goal of making inline assembly unnecessary, even at the highest performance tiers.
These patterns are powerful but verbose and reappear across kernels, so we briefly introduce POET (Performance Optimized Excessive Templates), a header-only library usable from C++17 onward that packages the most common cases as ready-to-use building blocks, alongside xsimd for portable SIMD.
As a concrete case study, we walk through a real scientific-computing kernel — a workload of the kind that has historically demanded hand-tuned assembly — and show how these abstractions get within a small fraction of theoretical peak throughput while keeping the source readable, portable, and maintainable, with no inline assembly, no compiler builtins, and no external code-generation step. Scientific computing does not have to choose between performance and engineering quality, and with the right abstractions, development becomes dramatically more effective.
In the C++ world, it is often assumed that proper object lifetime management ensures a memory footprint that scales with an application’s actual needs. However, long-running systems are frequently sabotaged by heap pinning: a phenomenon in which Resident Set Size (RSS) refuses to shrink even after significant deallocations. This results in a critical, 'invisible' overhead that defies standard leak-detection tools and can lead to system thrashing and even Out Of Memory (OOM) kills.
Heap pinning occurs when long-lived allocations are interleaved with transient ones, creating a structural barrier that prevents the underlying allocator from releasing memory back to the system. A single persistent allocation can 'pin' an entire block of physical memory, forcing the OS to keep it mapped even if the surrounding space is empty. Consequently, the process footprint reflects historical peak usage rather than the current live state.
In this talk, we will bridge the disconnect between C++ deallocations and physical memory reclamation. You will learn to use allocator-aware objects and std::pmr resources to eliminate pinning by strategically segregating allocations based on their expected lifetimes. We will also demonstrate how to diagnose these 'ghost' overheads when traditional heap profilers fall short. You’ll leave the session equipped to identify and resolve these fragmentation traps, ensuring your application’s memory footprint finally stays proportional to its actual state.
Nicolas Arroyo has spent two decades crafting C++ in high-stakes environments, spanning VoIP, embedded systems, distributed systems, and low-latency financial infrastructure. Currently, he specializes in building performance-analysis tooling, system-level benchmarking, and eliminating... Read More →
Refactoring is defined as "the process of changing a software system in a way that does not alter the external behavior of the code yet improves its internal structure", and is a core skill and process in modern software development. From "cleaning up a little mess" to handling legacy code to improving testability to completely changing architecture, refactoring is the process to achieve that elusive thing, "clean, elegant, and maintainable code".
This talk will cover the basics of Refactoring from three angles. First, we will cover a few of the most important refactoring techniques and connect them to other well-known points of good C++ style.
Second, we'll talk about how to decide what and where to refactor. Common "code smells" are good places to start, but we will also discuss how to look for "seams" along which code can be cut, and how to find hints left in the code by previous developers that can point the way.
Third, we'll discuss how to successfully execute refactoring, even on a busy team and a big code base. What is the "blast radius" of a change, how to minimize the disruption it causes, and how to avoid annoying co-workers in the process.
Dave Steffen completed his Ph.D. in theoretical physics at Colorado State University in 2003, and promptly changed course for a career in software engineering. He has worked primarily in defence and aerospace, and is currently a technical lead at SciTec Inc.'s Boulder office. For... Read More →
What makes an async workflow readable? Not just linear control flow — you also need to see where errors go, what each step depends on, and how failures compose. This talk takes a single production workflow — multiple async RPC calls with conditional branching, parallel fan-out, and partial-failure handling — and shows it implemented in three paradigms: callbacks with thread pools, a workflow orchestration graph over futures, and coroutines with std::expected. We evaluate each through four questions: where does the control flow live, the error flow, the coupling, and the migration risk?
Coroutines restore linear control flow, but without structured error composition, the workflow drowns in manual failure checks at every step, that is more error-handling code than business logic. Task
Futong Liu is a software engineer at Bloomberg, where he works on distributed backend systems for financial infrastructure, with a focus on trading systems built in modern C++. He holds a master’s degree in Computer Science from EPFL. His work spans asynchronous programming, service... Read More →
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.
Andy Soffer is a lapsed mathematician turned software engineer. He spent eight years at Google, before founding BrontoSource in late 2024. His time at Google culminated in leading the C++ Core Libraries team (responsible for Abseil and GoogleTest) and the C++ Large Scale Refactoring... Read More →
For the first time in a generation, the C++ Standards Committee has a new convenor. Meet Guy Davidson.
In the decade since joining the Committee, Guy has not personally authored wording that made it into the Standard. Yet, he exemplifies what the role demands: the ability to work intently, iterate relentlessly, absorb setbacks, adapt, and return stronger. He pairs that with a deep commitment to guiding the evolution of a language that underpins much of the modern world – and a rare talent for setting aside ego to build consensus. Sometimes, he even does it in iambic pentameter; at others, in the rhythm of a sea shanty.
In this fireside chat, Guy will reflect on what it means to inherit an institution, his first months in the role, and the moment 118 hands rose in support of C++26 – while Bjarne Stroustrup’s did not. He’ll also share his own work: projects aimed at expanding C++’s capabilities, including an idea inspired by game engine design that has caught the attention of leading climate scientists.
Head of Engineering, Six Impossible Things Before Breakfast
Guy Davidson is the Head of Engineering at Six Impossible Thing Before Breakfast. Before that, he was the Head of Engineering Practice at Creative Assembly, one of the UK's oldest and largest game development studios.
Guy started writing games over 40 years ago, spending 24 of them at Creative Assembly and being at Six Impossible Things Before Breakfast since January 2024. He is the co-author of Beautiful C++: 30 Core Guidelines for writing clean, safe and fast code, published by Pearson in 202... Read More →
Modern C++ development involves much more than compiling source files. Cross-platform builds, dependency management, C++ modules, package metadata, SBOM generation, CI infrastructure, and distributed builds have all increased the complexity of software engineering over the last two decades.
CMake has evolved alongside those challenges.
This talk explores how modern CMake helps make difficult software-engineering problems more manageable through targets, dependency modeling, metadata generation, debugging tools, and scalable build orchestration.
We will examine how CMake supports C++20 modules, including dynamic dependency scanning, build graph updates, and import std.
We will also look at CPS and SBOM generation together: CPS provides machine-readable package metadata, while SBOM support helps CMake expose software supply-chain information from the dependency graph.
Next, we will discuss debugging CMake itself using the CMake debugger protocol, and debugging builds using the CMake Instrumentation API to understand where time is spent during configuration and build execution.
Finally, we will examine distributed execution and build acceleration, exploring options available to CMake users in both open-source and commercial environments.
Along the way, we will discuss the real-world challenges, trade-offs, and lessons learned from evolving a long-lived build system to meet the demands of modern C++ development.
Mr. Hoffman is a founder of Kitware and currently serves as CTO. He is the original author and lead architect of CMake, an open source, cross-platform build and configuration tool that is used by hundreds of projects around the world. Using his 20+ years of experience with large software... Read More →
Modern C++ gives developers powerful tools to write cleaner, safer, and more expressive code — but many production codebases still suffer from excessive boilerplate, repetitive patterns, and verbose implementations inherited from older C++ styles.
This talk explores practical modern C++ techniques that significantly reduce lines of code while preserving readability, maintainability, and runtime performance.
Through real-world examples, we will refactor traditional C++ implementations using features such as ranges, structured bindings, constexpr, concepts, CTAD, lambdas, std::optional, std::variant, and std::expected. We will examine where these features genuinely improve code quality — and where they can accidentally hurt clarity or performance if misused.
The session also goes beyond syntax improvements by analyzing generated assembly, compiler optimizations, allocations, and benchmark results to validate whether “shorter” code truly remains zero-cost.
Attendees will leave with practical patterns they can immediately apply to modernize existing codebases, reduce unnecessary complexity, and write more expressive C++ without sacrificing performance.
Seasoned software developer with over 7 years of experience specializing in modern C++ development across industrial automation, semiconductor manufacturing, and enterprise systems. He currently works as a Technical Lead Software at Applied Materials, where he architects and implements... Read More →
The C++ Core Guidelines is quickly gaining popularity as the main C++ coding standard in the industry. The official introduction of the standard states the following: "Many of the rules are designed to be supported by an analysis tool. One way of thinking about these guidelines is as a specification for tools that happens to be readable by humans."
We took up this challenge: we built the tools, implemented a subset of the C++ Core Guidelines, and applied them to more than 8,000 industrial embedded software projects. That was not an easy undertaking, because the defined “rule enforcements” contain all kinds of caveats, shortcomings, unclarities, exceptions etc.
During this talk, we will explore the conceptual obstacles we encountered during implementation, how we have addressed them, and what remains to be done to make the C++ Core Guidelines the de facto standard in C++ programming.
Paul Jansen (1967) graduated from the University of Amsterdam in computing science and philosophy (both cum laude). At Philips Research he was a computer scientist in the field of compiler construction and domain-specific languages. After a brief stay at Atos Origin and QA Systems... Read More →
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.
I’m an engineering lead at Microsoft, building tools that make software development more accessible and boost productivity for millions of developers. I’m passionate about native code and C++.
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.
I help CEOs and founders of high-stakes companies secure and scale their technology without the noise.
As a Fractional CTO/CISO, I bring 35+ years of experience designing and safeguarding systems where failure isn’t just a bug - it's a lawsuit, a breach, or a tragedy.
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.
David Li is the Game Developer Product Manager at Visual Studio with 12 years of experience in the software industry. As a gamer himself, David is especially passionate about enhancing game developer productivity through improving tooling for Visual Studio. In his free time, he enjoys... Read More →
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++.
Steve Sorkin has been at Bloomberg since 2019, where he is a senior software engineer. He is enthusiastic about writing clean, scalable, and maintainable code for use in low latency and high throughput applications. Prior to joining Bloomberg, Steve worked as a securities/derivatives... Read More →
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.
Snikitha Siddavatam is a Computer Science and Data Science student at the University of Wisconsin-Madison, expected to graduate in May 2027, with coursework spanning machine learning, artificial intelligence, distributed systems, data visualization, and advanced algorithms. Snikitha... Read More →
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.
The C++ standard is moving more and more in the direction of safety. In the process, the committee is providing us with tools to help make our own code safer.
Many of these tools are specifically around numerics and none of them are enabled by default! To make matters worse, most C++ programmers don't even know these library features exist! Even if they did know, they wouldn't use them, because they are far too wordy.
We're going to do a survey of the relatively recently added new numeric safety related language features and see how they might come together in a real-ish project.
Jason is host of the YouTube channel C++Weekly, co-host emeritus of the podcast CppCast, author of C++ Best Practices, and author of the first casual puzzle books designed to teach C++ fundamentals while having fun!
To write the best C++ application code, you must think like a library author. This talk reframes application development as a form of library design, where every component is a potential asset for future maintenance and extension.
We'll survey the C++ language features that empower library authors to create powerful, flexible, and safe abstractions. From there, we'll distill the 'library author mindset.’ You will leave with concrete principles and techniques to make your application code more modular, maintainable, composable, reusable, testable, and ultimately, more valuable.
Jon Kalb is using his decades of software engineering experience and knowledge about C++ to make other people better software engineers. He trains experienced software engineers to be better programmers. He presents at and helps run technical conferences and local user groups.
Jon is passionate about quality code and wants to inspire others to achieve their best engineering work. He is excited about modern C++ and how we can exploit the latest hardware developments with standard, portable C... Read More →
As legacy C++ codebases evolve to meet new requirements, fix architectural issues, and address performance bottlenecks, refactoring becomes inevitable — but full rewrites are risky, costly, and rarely practical. This talk explores how modern C++ features — especially functional programming techniques and type erasure — can be used to refactor and extend legacy systems. We will present a concrete, low-risk, and measurable four-step technical framework for incremental modernization, by leveraging pure functions, discriminated union types, and type-erased callables to achieve safer, more flexible code with compile-time guarantees, even in traditionally object-oriented codebases.
The core of the talk will walk through the entire process on a concrete code example, illustrating (1) how to isolate existing logic, (2) define safer data models using immutable types, (3) deploy type erasure to create a robust, non-disruptive adapter boundary between old and new code, and (4) measurably execute the migration with safe testing practices. We will also share lessons learned from real-world experience and conclude by showing how these foundational patterns can be extended into future-thinking designs, leveraging examples with accepted C++26 features. Every step is grounded in real production constraints and trade-offs, and the techniques transfer directly to any domain where full rewrites are not an option. Attendees will walk away equipped with practical strategies to incrementally refactor your legacy systems without sacrificing stability or velocity.
Jessica Ding is a software engineer at Bloomberg, where she develops and maintains robust, high-performance trading and order management solutions that enable efficient execution, monitoring, and management of complex orders across global markets. Jessica earned her bachelor’s and... Read More →
You found the perfect C++ library. But you cannot integrate it with your CMake build without reading three pages of bespoke instructions. The documentation (if any) is a Doxygen-generated API dump. You file a bug, get "read the source," and move on. You never adopted it—and you had every intention of doing so.
Or you are the author of that library. Technically brilliant. Six months after release: three users, no contributors, two support tickets, you are not sure how to answer. Drawing on years of experience as both a maintainer of mp-units — a high-visibility, standards-track C++ library — and as a developer who regularly evaluates and contributes to third-party C++ projects, I have watched this pattern repeat across dozens of technically excellent libraries. The barriers that drive users away, frustrate potential contributors, and quietly kill great projects are predictable. More importantly, they are fixable.
This talk traces the five stages every C++ library must survive — Discovery, Evaluation, Integration, Contribution, and Community — and examines the concrete engineering decisions at each. We will look at how naming, README structure, and CI signals communicate trust to a user who found you three seconds ago; how a properly fuzzed build matrix gives users real confidence across their compiler, their C++ standard, and their platform; how DevContainers and Compiler Explorer eliminate the local setup barrier for both users and contributors; how the Diátaxis framework turns a documentation site from a reference graveyard into a system that serves newcomers, practitioners, and design-curious contributors; and how to craft an AI contribution policy that manages the rising volume of LLM-generated PRs without sacrificing the architectural integrity that makes a library worth contributing to in the first place.
Whether you are a user evaluating libraries, a developer looking for a C++ project worth your time, or an author trying to build one, you will leave with a concrete, field-tested checklist.
C++ Trainer | Principal Engineer, Train IT | Epam Systems
A software architect, principal engineer, and security champion with over 20 years of experience designing, writing, and maintaining C++ code for fun and a living. A trainer with over 15 years of C++ teaching experience, a consultant, a conference speaker, and an evangelist. His main... Read More →
Every mature codebase carries history and technical debt. The challenge is modernizing without stopping the world or introducing big re-write failure risks.
In this talk, we’ll explore how to modernize legacy C++ codebases incrementally using a mix of deterministic code transformations and AI-assisted refactoring .
After delving into some of the common problems with legacy modernization, we'll start tackling the simple "boring" stuff that deliver huge leverage of changes via clang tooling . These represent repeatable, deterministic reviewable upgrades that can be automated and applied at scale.
Then we can look at more difficult transformations that can be AI assisted with more aggressive transformations including API improvements and how to prevent it going off the rails. This will be backed by Compiler diagnostics, static analysis and testing to keep changes maintainable and correct .
The goal is not to replace engineering judgment, but to accelerate it: turning modernization into a continuous, low-risk workflow instead of a disruptive project.
Attendees will leave with a repeatable playbook for modernizing legacy codebases incrementally, safely, and at scale—using the right tool for each class of change
Pete Muldoon has been using C++ since 1991. Pete has worked in Ireland, England and the USA and is currently employed by Bloomberg. A consultant for over 20 years prior to joining Bloomberg, Peter has worked on a broad range of projects and code bases in a large number of companies... Read More →
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.
John Lakos, author of Large-Scale C++ Software Design (Pearson, 1996), is currently exploring the application of AI to large-scale C++ software design. From 2001 to 2026, he served at Bloomberg LP in New York City as a senior architect and mentor for C++ Software Development worldwide... Read More →
