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.

This Language Designers Panel features three of the people who decide what the languages you use every day actually become:

• Bjarne Stroustrup, the creator of C++ (who will have just given his own Monday conference kickoff keynote the day before)
• Guido van Rossum, the creator of Python
• Mads Torgersen, the lead designer of C# and Anders Hejlsberg’s successor in that role
• Moderator: Emma Tracey, founder of CultRepo and producer of its new feature film C++: The Documentary and Python: The Documentary

Three living and growing languages used by millions of developers, three design philosophies, one stage, one conversation.
Bjarne and Guido have never been on stage together anywhere and may never be again; add Mads to the stage, and we expect this special moment to be watched, cited, and argued over for years. You can be in the room when it happens.
Why should a C++ audience care about a panel that is two-thirds “other languages”? The answer is that these languages are two of C++’s closest neighbors and are used together all the time.

• Python is, by the numbers, C++’s truest sister language. In the Standard C++ Foundation’s annual C++ developer survey, when we ask which other languages C++ programmers use, Python always comes first, consistently around 70 percent — ahead even of C, which you might expect to win and is consistently around 45 percent. If you write C++, the odds are very good that you also write Python; the two have grown up side by side, gluing and being glued, and the relationship only deepens each year.
• C# and C++ are the two dominant languages on Windows, and the two are constantly used together — native performance underneath, managed productivity on top — so the person designing C# is designing part of the world that a great many C++ developers ship into.

So this is a conversation among the architects of the three languages most of us actually live in. What do they envy in one another’s designs? Where do they think they got it right, and where would they start over? How do you steer a language with millions of users and decades of existing code without breaking the people who depend on you? And the lessons to learn from their shared experience reach well beyond language design — the same instincts that shape a language will sharpen how you design your own libraries and products. Bring your own questions, too — you will not get a chance like this often.

At scale, writing C++ becomes a different engineering discipline. Problems that appear secondary in smaller systems — dependency boundaries, build graph stability, toolchain inconsistencies, integration latency, ownership, and deployability — become first-order constraints.

In production HFT, a single core infrastructure repository may contain 26+ million lines of C++ across 100K files, organized into 250+ distinct subprojects: exchange gateways, feed handlers, protocol codecs, shared risk libraries, replay frameworks, and strategy infrastructure. That shared foundation is continuously modified, rebuilt, tested, and deployed by engineering teams across five time zones and more than 40 trading teams, each maintaining their own siloed multi-million-line client systems in C++, Rust, and Python.

Under these conditions, many accepted “best practices” simply do not survive contact with reality. Systems must instead evolve toward what might be called a ground state: components reduced to their essential boundaries and responsibilities, abstract enough to support radically different workloads, but precise enough to compose into a coherent whole.

The challenge is not merely writing fast code. It is building systems that remain correct, flexible, and evolvable while operating under constant latency and operational pressure.

This is not a talk about “perfect architecture,” but about the tradeoffs, hard-earned lessons, constraints, and occasional failures through which generations of engineers — myself included — have kept large systems moving forward without stopping the business behind them.

This session dives deep into the world of vulnerabilities from a C++ developer's perspective. Using a simple embedded device as the playground, where the memory model is stripped to the bare essentials, attendees will explore how classic attacks like buffer overflows can be used to hijack control flow, inject code, and manipulate the stack.

Everyone has heard the warnings about buffer overflows, use-after-free, memory corruption, and other infamous vulnerabilities lurking in low-level code. But many developers accept that these traps should be avoided without truly understanding how the exploits work. In this talk, attendees will see hands-on examples of how memory vulnerabilities arise, how they’re exploited, and why they’re dangerous.

But this session is not just about breaking things, it is about building them right. We will explore how modern C++ techniques like smart pointers, bounded containers, and RAII can prevent these issues altogether. By the end of the talk, developers will not only understand the risks but feel confident applying C++ best practices to write safer, more robust code.

Whether you are a systems programmer, embedded developer, or security-minded engineer, this session will deepen your understanding of C++, not just as a powerful language, but as a tool for writing secure, reliable software.

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.

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.

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.