CppCon 2026

Join us for the Women++ Networking Breakfast!

Kick off CppCon with a relaxed breakfast for women and LGBTQIA+ professionals on Tuesday,
September 15, from 07:00–09:00.

Meet fellow C++ engineers over coffee, breakfast, swag, and light activities designed to spark
meaningful conversation before the conference begins.

Sponsored by Seven Research, the event will also offer a chance to learn how C++ expertise
can make an impact in quantitative finance.

Please RSVP early so we can plan breakfast and swag for everyone.

Register here to join us

About Seven Research

Seven Research is a quantitative research and technology company developing
advanced systems for the global markets. We bring together quants, strategists, and

technologists to design scalable models, systematic strategies, and high-performance
infrastructure built for speed, precision, and robustness.

Our quants work on complex market problems, developing models, signals, simulations,
and strategies that translate research into real-world trading systems. Our developers
build the technology that powers that research and execution, from low-latency C++
systems to simulation platforms, high-performance computing, and tools that accelerate
the entire research process.

If you’re interested in solving hard problems alongside a close-knit technical team in a
flat, collaborative environment, visit our careers page to learn more about our open
roles.

Tower Research Capital hosts a dynamic, Reddit-style "Ask Me Anything" session at CppCon featuring Justin Zaglio, Principal Software Engineer, Risk Limits, and Vincent Marsicano, Global Head of Technology Talent Acquisition at Tower that puts the spotlight on real-world applications of C++ in one of the most demanding environments: global quantitative trading. The 45-minute session will open with a brief look at how Tower leverages C++ to power its high-performance trading infrastructure, before turning the floor over to attendees for an open Q&A.

Native C++ types often become the format for bytes that cross a boundary: shared-memory IPC, plugin interfaces, persistent storage, or software built for more than one ABI. At that point the type is no longer just an implementation detail; it is part of a binary contract. trivially_copyable , sizeof , and code review help, but they do not answer the two questions that matter: may this type be transported as bytes at all, and do all supported ABIs give it the same object representation?

C++26 reflection can derive that evidence from the type itself. The technique builds a compile-time layout signature from ordinary C++ types, without IDL, generated stubs, or runtime inspection. The signature records the representation facts needed for byte transfer: architecture and endianness, leaf type tokens, sizes, alignments, absolute offsets, bit-fields, and pointer-like markers. It deliberately leaves out field names and source-level meaning.

With those signatures in hand, the build can enforce a gate for memcpy-style transfer. You name the boundary types and supported ABIs. Each target exports signatures, and a verification build permits direct byte transfer only when the type is byte-copy safe and the signature matches across the set. We'll walk through the workflow with static_assert checks and CI diagnostics: a fixed-width type that passes, a pointer-containing type rejected by admission, and a platform-divergent type rejected by signature comparison. The claim is intentionally narrow: representation compatibility, not semantic compatibility or schema evolution.

This talk is the 2026 edition of our series that highlights low-latency, networking, parallelism, and concurrency proposals to the C++ Standards Committee, especially those discussed in the Kona 2025, Croydon 2026, and Brno 2026 meetings. This talk from the Concurrency TS2 Editors, DG and SG14/19 chair will describe the following features and show how they can be used. It will also give their motivation, background, and their place within the overall framework of C++ low latency, networking, parallelism and concurrency:

Atomic Compare and Hazard Pointers Reclamation Control

• We discuss a proposal for atomic compare operations that clarify programmer intent and simplify static analysis by avoiding the unnecessary leakage of atomic values. We also explore how these operations complement recent proposals to enhance the expressiveness of atomics, such as the use of tagged pointers.
• We examine techniques for controlling C++26 hazard pointer reclamation, demonstrating how to offload retirement overhead to asynchronous executors to ensure predictable thread latency. We show how this capability can prevent specific deadlock scenarios and assess whether such controllers should be standardized or remain user-space patterns.

Twenty-One Years Without Sockets, The History of Networking in C++ and What We Learned Along the Way

• Go has standard networking. Rust has standard networking. C++ has been trying since 2005. This talk tells the twenty-one-year story in seventeen minutes: the library that shipped but never standardized, the dependency that blocked it, the coroutine revolution that changed the assumptions, the technical discovery that explains why I/O doesn‚Äôt fit the three-channel model cleanly, and the bridge that lets both models win. Three decision points, three lessons, one live question: how should coroutines and senders coexist for C++29? No villains. Just the story and the engineering. Networking is now finally a C++29 priority, so said the Direction Group‚Äôs P5000.

Out-of-Thin-Air (OOTA) Values.

• The memory models for high-level languages, including C++, C, Rust, and even Java, have been prone to out-of-thin-air values. For example, given two atomic integers X and Y, both initially zero, if one thread does a relaxed assignment from X to Y and the other does a relaxed assignment from Y to X, the mathematical C++ memory model does not rule out the outcome where both X and Y have the value 42. However, both communication and computation take time, and so we have proven that OOTA values cannot happen on real-world production-quality computer systems. This result makes compiler-writers‚Äô lives easier, and also eases the jobs of those brave individuals pursuing the full mathematical OOTA problem by relieving them of the need to live within CPU and memory constraints of production-quality compilers.

Discussion

There are other features under discussion, but the features we will present seem close to approval, are particularly interesting, and/or are relatively non-controversial. We will show use cases for each and prognosticate their journeys to C++26 and beyond. This will help programmers in concurrency, lock-free programming, and low-latency applications understand how best to take advantage of each of these important facilities.

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.

Reverse-mode automatic differentiation (AD) computes exact gradients with respect to thousands of inputs in roughly the time of a single function evaluation. If you write numerical C++ for finance, scientific computing, or ML and you care about performance, this talk will show you where AD overhead actually comes from and what to do about it.

A straightforward operator-overloading implementation records every arithmetic operation onto a tape and replays it backward to propagate derivatives. On real numerical code this easily introduces 50-100x overhead, and most of that has nothing to do with calculus. It is heap allocation on every operation. It is cache misses walking the tape backward. It is branch mispredictions at memory chunk boundaries. It is recording tape entries for operations where none of the operands are even being differentiated.

We work through a series of C++ techniques that bring this down to around 4x on production code in finance. The two that matter most: a chunked arena allocator with cache-line alignment and branch-prediction hints that turns the recording hot path into a pointer bump and a store, and expression templates that collapse an entire right-hand side into one tape push with all derivatives accumulated in a compile-time-sized stack buffer. We pull up compiler output to show the abstraction really does compile away.

After the big two, we get into the smaller wins that are still worth knowing about: skipping zero adjoints during the backward sweep to exploit sparsity, picking derivative formulas at compile time that reuse the forward result instead of recomputing it, and demoting active-times-passive operations from binary to unary to halve their tape footprint. We also show how a should-record check propagated through the expression tree lets the tape skip entire statements when no operand is active, and how aggressive inlining lets the compiler eliminate these checks entirely for passive subexpressions, so the cost of asking is zero when the answer is no. We benchmark each one in isolation on four numerical workloads ranging from 8 to 161 sensitivities, so you can see what each technique is actually worth.

Modern C++ development spans platforms, build systems, and increasingly complex project structures. In this landscape, Visual Studio Code has carved out its distinct position as a lightweight, extensible editor that works where you do, with first-class extensions built on decades of C++ language services and build system integration. This year's update deepens both of those foundations and opens them up to AI-driven workflows powered by GitHub Copilot.

This session walks through what's new across three dimensions of C++ development in Visual Studio Code. For the inner loop, we'll cover practical improvements to everyday compile-test workflows, including CMake target bookmarks and Run Without Debugging. For writing and understanding code, we'll show how the C/C++ extension's language services now surface rich project understanding to GitHub Copilot, giving AI assistance real awareness of your code structure instead of relying on generic pattern matching. For your workflow, we'll demonstrate how AI capabilities compose across different modes of working: inline suggestions for hands-on editing, agent coordination for multi-file refactoring, and CLI sessions for long-running tasks and deeper codebase analysis you can revisit on your own schedule.

Throughout the session, we’ll use real-world C++ problems to demonstrate where these tools meaningfully improve productivity and where they intentionally stay out of your way. Finally, we’ll show you how to inform GitHub Copilot about your team's best practices and scale them across your code through extensibility points like skills, custom instructions, and custom agents.

Tooling Track sessions are sponsored by Optiver.

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.

Recruiters Pri Trivedi and Brian Leone of Bloomberg will spend their lunch answering your career-related questions. Bring all of them.
Which college classes build a strong first CV? How should you handle a technical interview? How can you learn and grow by participating in and contributing to open source? What does a first job actually look like? Why is C++ still deeply valued, and where can your experience with it get you hired? What role will AI tools play in building a career that matters?
Bloomberg is hiring, and Pri and Brian will happily talk about that. However. this is a lunch, not a pitch, so the agenda will follow whatever the room asks - no question is too basic. Students are especially welcome to attend.

AI is changing how we code — we prompt more, type less, and review instead of create. Productivity may be up, but many developers feel the loss of flow, reduced ownership, and a sense that the craft is slipping away.

What if we're looking for joy in the wrong place?

This talk explores how AI reshapes the experience of programming. We'll revisit what made it fulfilling — solving problems, reducing complexity, exercising judgment — and build a new mental model where clarity and taste matter more than typing.

AI changed the craft's shape, not its soul.

Poster presenters will be available for an additional Q&A at their posters, in case you weren't able to make the session Sunday night, or if you would like to discuss the presented topics in more detail.

A fundamental control structure of each programming language are loops. And we all expect them to be simple and self explanatory. However, C++ would not be C++, if there would be no tricky details to learn and respect about loops in C++.

This talk takes its time to discuss the various ways and approaches to program loops in C++. Beside basic while and for loops, we talk about the range-based for loop, and all the extensions recently added to these control structures.

In addition, we will look at other ways to program loops in C++, such as using algorithms and how to deal with parallel computing in a loop.

As a result you get a deeper understanding of the various ways loops can be programmed in Modern C++ so that you know better how to use them in practice.

Atomic memory ordering is often taught operationally: Use acquire here, release there, and perhaps add a fence “to be safe.” This approach tends to produce cargo-cult synchronization, where atomic operations are selected mechanically without a clear understanding of what information is actually being propagated between threads. In practice, memory ordering is not about memorizing enum values, but about establishing which facts become visible to which observers, and when.

This talk approaches atomic synchronization from first principles. Beginning with the fundamental ideas of publication, visibility, ownership transfer, and synchronization edges, the talk incrementally develops several concurrent structures drawn from real asynchronous systems. Case studies include outstanding-work reference counting, a multi-producer singly-linked publication structure, a concurrently-mutated doubly-linked intrusive list, and the coordination machinery underlying a concurrent operation with multiple concurrent completion modalities. Each structure is used to derive the synchronization requirements imposed by its invariants, rather than selecting memory orderings mechanically.

Along the way, the talk explores the practical meaning of relaxed operations, acquire/release synchronization, and atomic thread fences. Particular attention is paid to understanding what each actually does, when it is necessary, and when it has become a decorative synchronization cargo cult. The goal is not simply to present lock-free algorithms, but to develop a principled way of reasoning about memory visibility and synchronization in real concurrent systems.

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.

Compiler Explorer looks simple: type code, get assembly. Underneath: a fleet of sandboxed machines running hundreds of compilers across dozens of languages, terabytes of binaries to keep current, and the ongoing problem of executing arbitrary code from internet strangers.

A lot has changed in the 14 years that the site has been around: The sandboxing layers that let it run other people's code without losing sleep. The storage situation that very nearly broke it, and the content-addressable filesystem that quietly rescued everything. The operational war stories, the migration sagas, and the bits that are far more boring than they look from the outside. Along the way you'll see some of CE's recent features in their natural habitat, and get a peek at what's coming next.

You'll come away with a working mental model of how to run untrusted compilation at scale - and why the parts that look easy are almost always the hard ones.

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.

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.

Most bosses aren’t stupid, they just seem like it sometimes! This can be especially so when a great programmer first becomes a manager – suddenly the very attributes that made them good at their job become a problem. Whether you’ve just been ‘promoted’ to a management position, you hope to be some day, or you want to know how to deal with a difficult manager – it’s very useful to understand the world from a boss’s perspective. Not all leaders are bosses (and not all bosses are truly leaders): if you want to get something meaningful done then you’ll need to influence other people.

Whether or not you're a boss, leadership is important. To do meaningful/large things, we need to work with other people. Encouraging and persuading peers in the right way will make your and your peers' working lives better.

Lots of war stories (anonymised to protect the guilty) and tips and tricks, this talk is basically 'how to win friends and influence people' for programmers.

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.

Last year, the title of this talk would have been "AI in a C++ World." That it isn't anymore tells you most of what changed.

A year ago, AI was the visitor we were evaluating. Now, it is the room we work inside, and the question for C++ programmers is no longer whether to take the technology seriously but how to keep doing serious work in its presence.

Another year of using these tools in earnest on production C++ has clarified what works, and given me an actual workflow to point at instead of a set of slogans.

I'm a professional C++ developer, and yet I haven't written a line of code since last November. Not because I've not written any code, but because AI has written every line.

It is not a theoretical presentation, but a working practitioner's report. I'll walk you through the development workflow I now use for serious C++ development.

Along the way I'll cover what C++ developers actually need to know about how LLMs work, what the agentic loop is, and how to get production-quality C++ out of these systems. The tone is practical, but opinionated, though those opinions are based on personal experience.

If you are not yet using AI as another independent member of your development team, or if you think I'm completely off my rocker, then this talk is definitely for you.

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.

The C++ Core Guidelines is quickly gaining popularity as the main C++ coding standard in the industry. The official introduction of the standard states the following: "Many of the rules are designed to be supported by an analysis tool. One way of thinking about these guidelines is as a specification for tools that happens to be readable by humans."

We took up this challenge: we built the tools, implemented a subset of the C++ Core Guidelines, and applied them to more than 8,000 industrial embedded software projects. That was not an easy undertaking, because the defined “rule enforcements” contain all kinds of caveats, shortcomings, unclarities, exceptions etc.

During this talk, we will explore the conceptual obstacles we encountered during implementation, how we have addressed them, and what remains to be done to make the C++ Core Guidelines the de facto standard in C++ programming.

Tooling Track sessions are sponsored by Optiver.

In modern C++, std::unordered_map is the de facto #2 container. Its dominance signifies a fundamental shift in application design: the performance-critical need for O(1) average-case key-value lookups.

Join as we move beyond "just use a hash map" and explore the critical, real-world implications of this choice. We'll start by benchmarking the classic std::map (red-black tree) against std::unordered_map (hash table) to understand exactly what you gain-and what you might lose.

However this power comes with risks. An average-case O(1) can quickly degrade to a catastrophic O(n) without warning. We will profile and dissect the actual costs of using a hash map:

• The Hash: What makes a good hash function? We'll go beyond std::hash and see how to write effective, fast hashers.
• The Collision: How do different collision-handling strategies impact performance and memory?
• The Re-hash: What is "load factor," and when does the hidden cost of a full table re-hash destroy your performance gains?

We'll conclude with a practical decision-making framework for when to choose std::unordered_map , when to fall back on the ordered std::map , and how std::string -the container we often forget is a container-fits into this modern landscape.

You will leave this session knowing precisely which data structure to deploy for maximum performance.

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.

Modern coding agents are incredible, but they still struggle with the kind of large, unstructured codebases that are common in C++. There are several techniques and tools that can make them perform much better. Here we show examples and demos of how to get your agent to work better with complex code. The focus is on providing an overview on current techniques and how we’ve found they work best. - Skills, memory and MCP - these have all been hyped hard, we’ll sort through where they are actually useful. - All agents (Claude, Copilot, Codex, Gemini) support these - some better than others. - What a skill is and what it isn’t - How to use persistent memory - Why MCP servers are still needed (but not always) - Context engineering. - Context management keeps changing - we’ve got autocompaction and 1M token windows now, why should we care anymore? - When to “manage” your agent’s context window and when it’s a bad idea - How to understand where context is being spent. - How and why to use subagents - these are almost always available but the capabilities in different frontends are exposed in different ways. - Spec Oriented Development: buzzword, euphemism for vibe coding or the future of programming? - What is it? - What tools exist? Covering options such as SpecKit, Kiro, etc. - Working in parallel with agent teams! - How to get started without having to learn anything (almost)! - Runtime context. - How to give your agent the best possible feedback path so you can stop micromanaging it and leave it to complete longer, more complex tasks. - Techniques including testing, CI integration and recording-based technology

Practical HPC — Forcing the Compiler's Hand with Modern C++

Achieving near-peak FLOPs on modern CPUs requires exploiting SIMD, register files, and cache hierarchies — yet the levers that matter most (loop unrolling, vectorization width, tile sizes, register tiling) are largely outside the programmer's direct control. Autovectorization is fragile, #pragma unroll is advisory and non-portable, and the information the compiler needs most — loop bounds, problem shapes, working-set sizes — is typically only available at runtime. The result is a familiar gap between theoretical peak and delivered performance, bridged in practice only by hand-written intrinsics or inline assembly, fragile macro forests, or external code generators that sacrifice maintainability and type safety.

Modern C++ is, sometimes surprisingly, an excellent language for closing that gap without leaving the host language. We walk through the concrete features that make this possible and how to use them in practice — templates and constexpr to promote runtime values into compile-time constants, if constexpr and parameter packs for shape-specialized kernels, generic and template lambdas for loop bodies that are unrolled and inlined by construction, and concepts to turn silent performance cliffs into compile-time errors. Together, these give the programmer precise control over what the compiler emits: compile-time dispatch that specializes kernels per shape and target, guaranteed static unrolling that unlocks ILP and register tiling without relying on optimizer heuristics, and hardware-aware specialization parameterized on register count, SIMD width, and cache sizes.

Looking forward, C++26 and static reflection push this approach considerably further, turning today's disciplined metaprogramming into something closer to first-class, in-language code generation — and squarely aligning the language with the goal of making inline assembly unnecessary, even at the highest performance tiers.

These patterns are powerful but verbose and reappear across kernels, so we briefly introduce POET (Performance Optimized Excessive Templates), a header-only library usable from C++17 onward that packages the most common cases as ready-to-use building blocks, alongside xsimd for portable SIMD.

As a concrete case study, we walk through a real scientific-computing kernel — a workload of the kind that has historically demanded hand-tuned assembly — and show how these abstractions get within a small fraction of theoretical peak throughput while keeping the source readable, portable, and maintainable, with no inline assembly, no compiler builtins, and no external code-generation step. Scientific computing does not have to choose between performance and engineering quality, and with the right abstractions, development becomes dramatically more effective.

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.

Clang is the C++ compiler used by hundreds of millions of developers every day, yet most of those developers have never looked inside it. The codebase can feel intimidating, with millions of lines of C++, an unfamiliar architecture, and a review process with its own customs. But once you know the map, contributing is surprisingly accessible.

This session is a live, code-first walkthrough of the full contribution cycle for Clang. Starting from a clone of the LLVM monorepo, we will configure a development build, locate the right subsystem for a real reported bug, write a regression test, fix the bug, and verify the fix. We will then extend that foundation to implement a small but complete language feature: adding a new diagnostic, walking through Sema, the AST, and the diagnostic engine as we go. Every step attendees see on screen can be replicated on their own laptops during and after the session.

Attendees will leave with a mental model of Clang's layered architecture (driver, frontend, Sema, CodeGen), a workflow for finding the code responsible for any given compiler behavior, and enough familiarity with the test infrastructure and review process to open their first pull request.

Tooling Track sessions are sponsored by Optiver.

AI coding demos almost always use well-understood applications with canonical architectures. What happens when you build a one-of-a-kind C++26 application instead of another TypeScript web app?
I’ll use detailed metrics to compare the same application built three ways:

1. Manually with the latest C++26 features
2. Vibe coding it with the latest AI
3. In collaboration with AI

The code, the experience, and the outcomes differ in surprising ways, pointing to new best practices for AI-assisted C++ and beyond.