CppCon 2026

Every Boost library that graduated to the C++ Standard became invisible. shared_ptr doesn't say "Boost" anywhere. 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. Howard Hinnant. Marshall Clow. Beman Dawes. 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. Joaquín López Muñoz sat down, studied SIMD probing, and built something faster than a team at Google. Boost.Intrusive — presented as a magic trick before an explanation. One object, three containers, and zero extra allocations. 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 survey other recent additions.

Networking gets its own act. Beast, Corosio, Capy are 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.

We spend some time with related C++ Alliance initiatives to make the ecosystem safer and more robust. And a quick mention of the upcoming Boost Documentary.

We close not with a mailing list URL but with a name. One person, a contributor who used Boost for a decade, then brought their own work, took the reviews, and was mentored. They now help maintain Boost. 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.

Large-scale robotics organizations operate diverse fleets of manipulators — 4-DOF arms on rails, 6-DOF standard manipulators on pedestals and fully mobile manipulators — each with different kinematics, hardware vendors, and software teams and researchers.

And engineers and researchers are opinionated.

As a team eventually you have one goal. Re-use as many abstractions; ideas and algorithms as you can while still allowing you the flexibility to explore new algorithms; ideas and approaches.

This talk presents a layered C++ architecture that solves this at scale. We present our core abstrcactions; a header-only Lie group library provides shared spatial math types (SE(3) poses, twists, wrenches); a trajectory library for motion planners and controllers; and a collision detection library from the same.

We will discuss how we moved from virtual functions to C++ concepts with zero overhead and the learnings along the way that allow us to write planning and control algorithms for various robots morphologies and sensing paradigms.

Critically, this architecture balances the needs of production at scale while enabling experimentation: researchers can prototype new collision algorithms, try a new physics engine, or test a novel trajectory representation — all without disrupting production code. The backend boundaries are where new ideas enter the system. You'll leave with three distinct C++ patterns for backend abstraction — compile-time traits, runtime interfaces, and type erasure — and an understanding of when to use each based on performance requirements and the need for experimentation.

According to VGInsights, about 10% of games released on Steam in 2024 used a custom engine, but those games represent 41% of units sold. Most "how an engine works" talks come from the AAA end of that distribution. This one comes from the other end of that distribution: a teaching-scale engine, where every system has to be small enough to understand from first principles. The problems are the same as in a big engine, but the smaller surface is what makes the architecture legible.

In this talk, we'll walk the spine of the engine in modern C++: allocators and handles in the core, the job system, the graphics abstraction question, the asset pipeline split between pipeline-time and runtime, and scene representation including ECS. We finish on serialization, where C++26 reflection (P2996) offers a path past today's reliance on macros and external code generators.

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.

Applications that present rapidly changing market data to human users face a practical challenge: updates may arrive thousands of times per second, but humans only benefit from periodic refreshes. Efficiently coalescing and scheduling that work without overwhelming CPU resources becomes a concurrency problem rather than simply a rendering problem.

This talk demonstrates how modern C++ atomics can be used to build a lock-free timer scheduler optimized for extremely high update rates. The scheduler follows a single-producer, multiple-consumer design in which work items represent recurring tasks that must execute periodically. Consumers process scheduled work and re-schedule it for future execution without relying on traditional locks or centralized coordination.

The most unusual aspect of the design is its “reverse work stealing” behavior: consumers can proactively give away work to other consumers and become idle themselves. Rather than distributing work evenly across all threads, the scheduler attempts to pack work onto as few cores as possible, reducing idle spinning, lowering CPU utilization, and improving cache locality. Because tasks may have highly variable execution times, the scheduler must also prevent pathological cases where work is endlessly redistributed between consumers.

Attendees will learn how atomics, lock-free forward lists, and memory ordering can be combined to implement high-throughput schedulers with predictable latency characteristics. The talk also discusses practical tradeoffs, implementation challenges, and performance measurements from production-inspired workloads, including producer throughput of approximately 50 million scheduled tasks per second and consumer processing throughput approaching 700 million tasks per second, while keeping migrated work items below 1% in typical workloads.

Your system supports multiple strategies, with the user selecting one at startup, but each strategy must handle different semantics. Traditional runtime polymorphism can require a virtual override for every combination, making code harder to extend and easier to get wrong

This talk shows how OpenJDK solves this problem by using a layered architecture of compile-time patterns with a runtime trampoline. We'll build them up through OpenJDK's GC barrier system, where a single templated API stands in for dozens of differently-shaped memory accesses across the runtime: plain stores, raw/unsafe access, native calls, weak references, and more, each needing different treatment depending on the semantics and which garbage collector was chosen by the user.

We'll also discuss trade-offs against std::variant, function pointers, and plain virtual dispatch. No JVM knowledge required.

Application developers sometimes hit a limitation of a 3rd-party library or framework. The Type Erasure design pattern can help us overcome such limitations without the need to change the 3rd-party API.

Type Erasure is a relatively complex design pattern that allows us to treat a set of unrelated classes as if they shared a common base class, while preserving value semantics. The downside is increased code bloat and code complexity as the pattern requires a significant amount of additional code.

There have been quite a few talks explaining HOW to implement Type Erasure, while the topic of WHEN has been rarely discussed. Should we always use type erasure instead of virtual polymorphism? And if not, then what are the criteria?

This talk will show a concrete example from the audio programming industry of how Type Erasure allowed adding new functionalities to the parameter class system of the JUCE C++ framework without changing its API. As such, the talk will be useful for application and library developers who use 3rd party libraries but need an extra degree of flexibility.

You will come out of the talk understanding

• what Type Erasure is,
• when to use it, and
• how to implement it.

You don't need to understand Type Erasure, audio development, or JUCE to attend the talk; the necessary minimum will be explained during the talk.