CppCon 2026

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.

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

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

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

Benchmarks shouldn't live in a different world from tests. Most C++ projects already use Google Test, but the moment performance enters the picture, developers reach for separate tools, separate workflows, and ad-hoc timing loops that don't survive contact with CI. This talk argues for a different default: treat performance measurements as first-class tests. They are written in the same harness, run in the same suite, and fail the same builds.

Using a real C++23 framework built on top of Google Test, the session shows what that looks like in practice. Semantic macros distinguish throughput, latency, and contention tests; built-in statistical analysis tracks medians, percentiles, and coefficient of variation. Adaptive thresholds scale with payload size, so tiny operations and multi-megabyte workloads aren't held to the same stability expectations.

Once benchmarking lives inside the test framework, the rest of the performance toolchain follows. Five CPU profiler backends drop in behind a single --profile flag: perf, gperftools, bpftrace, RAPL, and callgrind. Attaching a memory profile to a test prints bandwidth, efficiency, and a CPU-bound or memory-bound classification with no extra code. The same harness extends to CUDA through a fluent kernel builder that captures launch configuration, achieved occupancy, transfer overhead, multi-GPU scaling efficiency, and thermal throttling. Nsight Compute drops in through the same --profile flag.

The payoff is CI integration that's nearly automatic. A companion CLI tool compares baseline and candidate runs, applies statistical thresholds, posts markdown reports on pull requests, and fails the build on regressions. The result is a single workflow for performance verification that scales from a developer's laptop to a CI runner to a Jetson on a workbench, across hardware ranging from x86 to ARM to RISC-V.