CppCon 2026

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.

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.