CppCon 2026

A fundamental control structure of each programming language are loops. And we all expect them to be simple and self explanatory. However, C++ would not be C++, if there would be no tricky details to learn and respect about loops in C++.

This talk takes its time to discuss the various ways and approaches to program loops in C++. Beside basic while and for loops, we talk about the range-based for loop, and all the extensions recently added to these control structures.

In addition, we will look at other ways to program loops in C++, such as using algorithms and how to deal with parallel computing in a loop.

As a result you get a deeper understanding of the various ways loops can be programmed in Modern C++ so that you know better how to use them in practice.

In low-latency C++, correctness is table stakes. What separates good systems from great ones is predictability — the ability to hit your deadline not just on average, but at the 99th and 99.9th percentile, where real workloads live. Latency is a feature, and if you don't design for it explicitly, you lose it accidentally.

This talk is a practitioner's guide to writing C++ that behaves predictably under load, drawn from experience building and tuning low-latency systems on Microsoft's Azure Core platform. We start from the mental models that matter most — CPU-centric thinking, the latency stack from L1 to DRAM, and why minimizing work, unpredictability, and memory movement is the foundation of everything else — and then work through the layers of the stack where latency is won or lost in practice.

Through live demos and benchmark data on both x86 and ARM, we'll cover:

STL containers as latency contracts — why most latency bugs start with the wrong container, the real cost of dynamic reallocation, and the measurable wins from reserve() and custom allocators.

Memory layout and cache behavior — struct layout and alignment (and how it differs on x86-64 vs. ARM64), AoS vs. SoA trade-offs, hot/cold data separation, false sharing, NUMA, and TLB pressure.

Atomics vs. mutexes — when atomics actually lose to mutexes, why architecture and memory model dictate the answer, and how to choose between them in real code.

Threading and scheduling — fixed vs. dynamic thread pools, context-switch and migration costs, and why understanding the OS is half the battle.

Benchmarking and observability — why microbenchmarks lie, how to avoid measurement bias and jitter, why latency histograms beat averages, and why "absolute benchmark" is a myth.

You'll leave with a practical playbook for designing and measuring low-latency C++ systems, an honest understanding of why benchmarks from one machine rarely generalize to another, and a sharper instinct for the silent killers — allocations, branches, cache misses, and synchronization primitives — that don't show up in code review but do show up in production.

Production C++ code often hides small but deeply complex algorithms inside layers of engineering: APIs, lifetimes, error handling, integration, logging, and glue code. We test classes and systems, but rarely the algorithm itself in isolation.

Off-by-one errors and broken or missing invariants can survive extensive pre-production testing. Line coverage does not imply branch coverage. Branch coverage does not imply coverage of algorithmic corner cases. Testing through a wide public API often obscures the mathematical structure of the problem, making subtle bugs difficult to discover through multiple layers of abstraction.

This talk explores how to extract an "algorithmic core" from a larger component. Its correctness is fundamentally mathematical and largely language-agnostic rather than C++-specific.

Using examples such as substring matching, topological sorting variations, and lazy evaluation on trees, we will examine how problem corner cases differ from implementation corner cases, and how easily some of them are skipped.

We will discuss:

• Recognizing when an algorithm is entangled with boilerplate
• Extracting core logic without introducing accidental complexity
• What it takes to test algorithmic code in isolation
• Raising the level of abstraction to make reasoning easier without merely relocating complexity
• Using LLMs to assist in exploring and validating implementations
• Gradual rollout and comparison of competing implementations

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.

This talk takes you through the research and optimization of radix sort, culminating in its integration into libc++.

You will learn : common pitfalls of radix sort implementations (non-binary digits, dynamic memory allocation, fragile interfaces), how to design a strict and high-performance interface (fixed digit size, external buffer, projection to integers), and how to overcome radix sort's main drawback — its lack of naturalness — with two counter-based optimizations and a hybrid merge scheme.

The result : on arrays of 60 int32 elements (18 for int8), radix sort starts beating std::sort ; on large arrays, it's up to 10x faster. Floating-point types (float/double/float16_t) are also supported via IEEE 754 bit transformations (sign and exponent inversion for negative numbers).

The key takeaway : in modern libc++, for integers and floats, std::stable_sort on random data is noticeably faster than std::sort . Life has become better, but also more complicated — choose your sorting algorithm wisely.