CppCon 2026

C++ gives us at least four different ways to pass "a thing that can be called" from one piece of code to another: function pointers, function objects, lambdas, and type-erased wrappers like std::function . Modern C++ has added more — generic lambdas, deducing-this lambdas, std::move_only_function , and a healthy ecosystem of concept-constrained callable parameters. Each of these has a job it is good at and several jobs it is bad at, but they are often used interchangeably until something breaks.

We will start with the basics: what a callable actually is, how function pointers, function objects, and lambdas relate to one another, and how the compiler thinks about each of them. We will look at lambda capture rules in detail — by-value, by-reference, init captures, dangling captures, and the cases where well-meaning developers reach for [=] or [&] and ship a bug — and we will see how generic lambdas (C++14) and deducing-this lambdas (C++23) extend the model without giving up clarity.

From there we will turn to the question of how to store and pass callables. We will compare function pointers, std::function , std::move_only_function (C++23), and concept-templated callable parameters along the axes that actually matter: ownership, allocation, move-only support, performance, and what the API tells the reader. Examples will be drawn from issues that have come up writing production code and mentoring developers — including the kind of subtle ABI and lifetime bugs that hide behind a perfectly reasonable-looking std::function<void()> parameter.

We will conclude with recommendations for which tool to reach for in which situation, with reference to the C++ Core Guidelines where useful. Attendees will leave with a clearer mental model of callables in modern C++ and a defensible default for the next time they write a function that takes one.

Teams writing modern C++ libraries with concepts, niebloids, deduction guides, and SFINAE-driven overload sets either accept wrong reference documentation or maintain a Doxygen + XSLT + Sphinx pipeline of workarounds. A different approach is to read C++ from the Clang/LLVM AST, separate corpus extraction from output templates, and recognize common idioms as first-class. This allows the source to stay clean from workarounds.

Doxygen-based pipelines all share these failures on modern C++. Constraint, noexcept, and explicit specifier expressions get truncated or dropped. Niebloids and function objects show as wrappers, not callables. Overloads distinguished by SFINAE or concepts scatter across the output, and CRTP base classes render with the wrong members. All of this disappears when the tool reads the compiler's AST and is able to instantiate specializations.

The talk then covers the architecture of MrDocs, an open-source documentation generator built on Clang/LLVM. Corpus extraction handles the redeclaration, template instantiation, and overload resolution problems that break naive AST traversal. Idiom recognition treats modern patterns as first-class metadata: niebloids, overload sets, concept constraints, requires-clauses preserved verbatim, function-object auto-detection, SFINAE overload sets, and deduction guides. It also captures the specifiers: explicit, noexcept, consteval, storage class, defaulted and deleted functions, and attributes. The templating layer gives full control over the output (HTML, AsciiDoc, Markdown, XML, or custom formats) without forking the tool.

The session is heavy on code from real C++ template libraries, with examples drawn from fmt, nlohmann/json, mp-units, and several Boost and Beman libraries. By the end, you will know why partial AST tools break on modern C++, what an alternative architecture looks like, and which idioms it has to recognize.

From our very first algorithms class, we are taught a simple rule: a better Big-O complexity means a faster algorithm. We spend years mastering asymptotic analysis, memorizing complexity tables, and losing sleep over worst-case scenarios. Big-O becomes a mental shortcut for “good” and “bad” code.

But the real world doesn’t run on whiteboards.

Modern performance is shaped far more by hardware realities than by asymptotic notation alone. CPUs have deep cache hierarchies, wide vector units, speculative execution, and memory systems that punish the “theoretically optimal” solution. GPUs thrive on massive parallelism where simple linear work can outperform asymptotically superior algorithms. Even on regular CPUs, cache-friendly linear scans often beat clever sub-linear approaches that fight memory latency.

In this talk, we will challenge the traditional Big-O mindset. We’ll look at classic algorithms through a modern lens and explore how hardware-aware designs cache-efficient layouts, SIMD/AVX vectorization, and parallel execution models can outperform algorithms with “worse” theoretical complexity. You’ll see why a higher Big-O algorithm can be faster, more scalable, and more predictable in practice.

The goal is not to dismiss Big-O, but to put it back in its proper place: as a tool, not a truth. By the end of this talk, you’ll think differently about performance and start writing code that works with the hardware, not against it.

C++ library maintainers are often in the dark as to everyone who actually depends on their code. Without that knowledge, deprecation decisions are guesses, the downstream impact of any API change is hard to predict, and the case for funding or continued investment is difficult to make rigorously. This talk demonstrates how mapping your downstream ecosystem changes the way you maintain and evolve a library, using dependent-audit, an open-source tool that discovers real-world dependents by searching public source code for #include directives and CMake integration files, and cross-referencing published academic citations. We'll show concrete examples of what this data reveals: where your true API surface lies, which users are candidates for upstream contribution, and how to make the case for your project's real-world significance. Attendees will leave with a lens for library stewardship built on data and ecosystem analysis