Optimizing a Spin-Lock

by David Álvarez Rosa

From the article:

A spin-lock is a lock that never sleeps. Instead of yielding to the scheduler, the thread stays on the CPU and spins. No syscalls. No context switches.

In this post, we’ll build a version, step by step, that is 5.7x faster while drawing 5.4x less energy.

Making sense of std::execution

by Mateusz Pusz

From the article:

At its core a sender is a value that describes work without starting it. You compose senders with algorithms into a pipeline, and the pipeline stays lazy until you explicitly run it.

Because the whole computation is a value up front, the things that were afterthoughts in every model above, where each step runs, what happens on error, and how the whole thing is cancelled, become first-class properties of that value. And coroutines are not left behind: they plug into the same model, so the readable co_await front end finally gets a real back end.

Published so far:

• Your async code is the goto of concurrency
• std::execution: structured programming, for async
• A pipeline is not an architecture

Building Safer Firmware in Modern C++, a live workshop with Packt

by Mateusz Pusz

The details:

• Wednesday 30 September 2026, 15:00 to 19:30 CEST (09:00 to 13:30 EDT), live online, hosted by Packt.
• Strong types and physical quantities with mp-units turn unit, bounds, and interface mistakes into compile errors. The generated assembly is then read to confirm the safety costs nothing at runtime.
• Everything runs in the browser on Compiler Explorer, so there is nothing to install.
• Tickets on Eventbrite.

Live online C++ masterclasses and open cohorts

by Mateusz Pusz

The details:

• Move Semantics and Forwarding References, Sunday 4 October 2026, 15:00 to 19:00 CEST. Value categories, move semantics, forwarding references, reference qualifiers, and the pitfalls around them.
• Name Lookup, Overload Resolution, and Customization Points, Sunday 6 December 2026, 15:00 to 19:00 CET. ADL, hidden friends, and the rules that decide which overload wins.
• Both run four hours live for up to 30 attendees, with hands-on exercises in Compiler Explorer and shared solutions reviewed in front of the room. EUR 99 plus VAT.
• The next open cohort is chosen by vote, open until 11 December 2026, between Advanced Modern C++ (5 days), Modern C++ Concurrent and Asynchronous Programming (4 days), Introduction to C++20 (5 days), and Mastering C++ Coroutines (2 days). The winning subject runs from Monday 22 February 2027.

Registration is now open for CppCon 2026!

Awaiters and Awaitables

Wednesday, September 16 09:00 - 10:00 MDT

by Mateusz Pusz

Summary of the talk:

C++20 coroutines come with a reputation for complexity — and writing your own coroutine return type deserves that reputation. But here is the good news: you probably don't have to. With std::generator in C++23, high-quality libraries like Asio and cppcoro today, and std::task on its way in C++26, most developers can simply write co_await and move on.

There is one gap, however. Sooner or later, every developer using coroutines needs to bridge an existing asynchronous interface — a timer, an I/O operation, a thread pool callback, a legacy future — into the coroutine world. That bridge is built with awaiters and awaitables, and that is exactly what this session teaches.

We will start from first principles: what does co await actually do? We will demystify the three functions that form the awaiter protocol — await ready, await suspend, and await resume — and build a clear mental model for each. We will implement a real awaiter from scratch, then explore how symmetric control transfer keeps the call stack flat across deeply chained async operations. Next, we will learn how to make any existing type co await-able without modifying it, using operator co await, and how await transform lets you restrict or adapt awaitable behavior to a specific coroutine context. Finally, we will look at how to write cancellation-aware awaiters using std::stop token, so your coroutines respond promptly when work is no longer needed.

No prior coroutines experience is assumed. If you know what co await looks like on the surface but not what happens underneath it, this session is for you. You will leave with both the knowledge and the code to wrap any asynchronous operation into a first-class co await expression.

Registration is now open for CppCon 2026!

Graphics Programming with SDL 3 Part 2

Monday, September 14 16:45 - 17:45 MDT

by Mike Shah

Summary of the talk:

Last year I introduced the SDL3 library which provides a solution for building games and graphical applications on multiple platforms. In this talk, we will continue our journey into SDL3, which newly includes the ability to write shaders within the built-in 2D API. My goal is to get you up and running fast by building out a small game application. Throughout the talk I will show how to build a small 2D framework, discussing design decisions and which C++ features can be used to help organize our code. Attendees will leave this talk ready to build multimedia / game applications and with an understanding on if SDL3 is the right tool for them.

Mike Shah is currently a teaching faculty at Yale University with primary teaching interests  in computer systems, computer graphics, and game engines. Mike's research interests are related to performance engineering (dynamic analysis), software visualization, and computer graphics. Along with teaching and research work, Mike juggles occasional consulting work as a 3D Senior Graphics Engineer in C++ and producing programming content at his YouTube channel https://www.youtube.com/@MikeShah

Why We Should Double-Check the AI Output: A Bug Which Wasn’t

by Giovanni Dicanio

From the article:

Recently I asked Claude to review the code of my WinReg C++ library. [...]

As a result of its analysis, Claude reported that there were zero-length bugs in my code, in particular Claude stated that zero-length REG_SZ/REG_EXPAND_SZ values crash the GetStringValue, GetExpandStringValue, TryGetStringValue and TryGetExpandStringValue methods of the RegKey class.

In particular, Claude noted that I correctly guarded against dataSize == 0 in the binary-returning getters (like RegKey::GetBinaryValue), but the string getters do not have such guard.

Registration is now open for CppCon 2026!

C++: Growing in a World of Efficiency, Safety, and AI

Friday, September 18 16:15 - 18:00 MDT

by Herb Sutter

Summary of the talk:

C++ is adding major expressive power (e.g., reflection) and addressing weaknesses (e.g., memory safety hardening) at exactly the moment when chip supply and power budgets are raising the value of what people came to C++ for in the first place: control over memory layout (space) and deterministic performance (time). This talk is about that convergence, in two parts.

First, we cover the latest developments in ISO C++ itself, where the committee completed technical work on C++26 in March 2026, and then in June voted the first additions into the working draft for C++29:

• Key C++26 language improvements like reflection and the initial round of memory safety hardening, and standard library performance enhancers like std::simd and std::execution.
• A new Annex in the C++29 working draft cataloging every case of core language undefined behavior, the first step toward addressing it systematically rather than one paper at a time.
• Draft “profiles” for stronger portable memory safety guarantees, now being prototyped and targeted at C++29.

Second, we consider how quickly both hardware and software are moving in the industry around us. This year, capital is pouring into silicon and power at a jaw-dropping rate, and agentic systems are arriving with new capabilities and new failure modes. We’ll see how both affect C++ programming in the trenches:

 

• Why performance efficiency has been enduringly important, from the 1940s through to today and with no end in sight.
• How current industry data (SlashData, IDC) documents sustained growth in demand for professional programmers, especially who know languages that can operate under real space and time constraints.
• What AI does and doesn’t change about any of it: a pragmatic view both of where AI has shown real benefit in our programming world, and of what it’s not good at (yet, or ever).

Throughout, we might hear a little grumbling from the speaker about how he has always written his own talk titles and abstracts and prose using em-dashes, but now can’t use em-dashes anymore because of, well, you know.

Herb is a technical fellow at Citadel Securities, designer of several Standard C++ features, chair emeritus of the ISO C++ committee, and chair of the Standard C++ Foundation.

Registration is now open for CppCon 2026!

The Address is Not The Place: Object Residency in C++26

Thursday, September 17 10:30 - 12:00 MDT

by Laurie Kirk

Summary of the talk:

Random Access Memory is what you buy when you don’t know what your program will do next.

Until recently, alternative tiers of memory with vastly different latency characteristics were largely speculative. Then DRAM got expensive. CXL memory pools, far memory, even high bandwidth flash moved from blips to serious contenders. C++ has grown its vocabulary for ownership (smart pointers) and lifetimes (RAII); but intelligent memory tiering, specifically object residency, is a word we don’t natively have.

Attempts have been made to solve this issue at an OS-level (Meta’s TPP), or even a compiler/runtime level (OBASE) but they approach the problem transparently by design. And thus…blind by design. You can improve tiered object locality with clever placement within pages, but all these methods are structurally incapable of predicting intent. What if the power was in the developer’s hands?

With reflection (P2996) and annotations (P3394), C++26 finally lets us extend the vocabulary ourselves. Game developers have deeply understood smart data grouping for decades, but much of the work is locked behind game engines; not suitable for general application development. [[likely]] and [[unlikely]] hint hot and cold paths, but the future of high-performance development hints at general purpose object residency to tier-aware allocators.

This talk introduces an open-source C++26 residency library, demonstrating capabilities against current, and even (simulated) future hardware. The pieces are in place for C++ to create durable abstractions for object residency; with the flexibility to accommodate memory tiers that have not been invented yet!

Laurie Kirk is a researcher at Google specializing in C++, reverse engineering, and deobfuscation. She runs a YouTube channel (@LaurieWired) that covers all sorts of in-depth research topics on reverse engineering, programming, and software optimizations. She has spoken at multiple conferences including ACCU on Sea, Strange Loop, DEFCON, REcon, and Objective by the Sea.

Registration is now open for CppCon 2026!

Profiles for Simplicity and Guarantees

Monday, September 14 08:30 - 10:15 MDT

by Bjarne Stroustrup

Summary of the talk:

The C++ community is growing fast. C++ is being used in critical applications. C++ can be used in ways that ensures correctness, simplicity, performance, and maintainability. How can we ensure that it is used is such desirable ways? How can we teach new and old C++ developers to do so?

The general strategy is called “subset of superset” and is based on the idea that by extending (“supersetting”) by adding libraries, we can simplify static analysis to where we can remove undesirable uses (“subsetting”) without damaging expressiveness or efficiency. Where run-time checks are necessary, such as to catch out-of-range accesses in hardened libraries, static analysis can be used to minimize the number of checks.

The strategy is supported by the “Profiles” framework, that allows us to require or suppress specific sets of guarantees, called profiles.

As examples, I show how to eliminate uninitialized-object errors and container-invalidation errors (a kind of dangling pointer errors) using the profiles framework and implementations of the “Initialization” and “invalidation” profiles. Both with zero run-time cost.

Registration is now open for CppCon 2026!

How C++26 Changes the Way We Write Code

Wednesday, September 16 10:30 - 12:00 MDT

by Timur Doumler

Summary of the talk:

The upcoming C++26 Standard is a major update of the language and one of the most impactful releases in the history of C++.

std::simd transforms high-performance C++ by raising vectorisation to a portable standard abstraction. The new sender/receiver execution library provides a powerful generic framework that redefines asynchronous programming in C++. Contract assertions introduce scalable and configurable correctness checks for identifying program defects and making C++ code safer. Finally, reflection – the most eagerly anticipated feature of C++26 – profoundly reshapes how we reason about C++ and what we can accomplish with it.

This talk is the third installment in a popular series exploring how each new C++ Standard changes the way we write code – from everyday idioms to advanced patterns – with a practical focus on what matters most to real-world developers. This is not a firehose talk that tries to cram as many additions to the latest Standard as possible into one hour. Instead, we focus deliberately on just a handful of particularly impactful features and highlight the essential ideas every C++ developer needs to understand.

Timur Doumler is a software engineer specialising in low-latency and real-time C++. He works at Citadel Securities and is an active member of the ISO C++ standard committee, where he has (co-)authored many successful proposals including [[assume]], std::inplace_vector, and contract assertions, and is currently serving as the chair of SG22, the C and C++ Liaison Group.Timur began his C++ journey in computational astrophysics, working on large-scale cosmological simulations. After completing a PhD in astrophysics, he spent a decade in the audio and music technology industry and co-founded the music tech startup Cradle. He has also worked at JetBrains, contributing to their in-house C++ frontend and later serving as Developer Advocate for the CLion IDE and other popular C++ tools.Timur is passionate about correct code, effective tools, and the evolution of the C++ language.

Registration is now open for CppCon 2026!

Language Designers Panel

Tuesday, September 15 10:30 - 12:00 MDT

Summary of the talk:

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.

When The C/C++ Users Journal Disappeared

by Chuck Allison

From the article:

Today, if you have a question, you search the web or have ask an AI chatbot. In the early 1980s there was the C Programming Language, but:

• there was no web
• there was no Stack Overflow,
• there was no GitHub,
• there was often no Internet access at all.

The C++ programming language had a creator, an organically emerging user community followed by a standards committee, and a vibrant ecosystem of writers and contributors.

The ecosystem part is often forgotten.

Registration is now open for CppCon 2026!

When Zero-Cost Abstractions Aren't Zero-Cost

Thursday, September 17, 2026 14:00 - 15:00 MDT

by Steve Sorkin

Summary of the talk:

Zero-cost abstractions are a foundational idea in C++, promising expressive, high-level code without sacrificing performance. However, developers often encounter unexpected costs when using modern abstractions in practice, even when the code appears idiomatic and well-designed.

This talk explores the assumptions behind zero-cost abstractions and examines what happens when those assumptions no longer hold. Through concrete examples drawn from modern C++ — including ranges and views, type erasure, allocators, and other common abstractions — we will examine how factors such as optimizer visibility, inlining boundaries, allocation behavior, and runtime flexibility influence performance.

This talk treats abstraction as a powerful engineering tool, examining the limits of its zero-cost guarantees in real-world systems. We will look at how seemingly small design choices can introduce hidden costs, why those costs are often difficult to spot through inspection alone, and how to recover performance without abandoning good design or readability.

Attendees will leave with a clearer understanding of when abstractions are truly zero-cost, how to recognize situations where they are not, and how to make informed tradeoffs between expressiveness, flexibility, and performance in modern C++.

Parallel Directory Traversal

by Daniel Gómez Vergel

From the article:

Given the path of a directory, our goal is to produce a statistical summary of the contents of its directory tree. For each file extension encountered (.txt, .zip, and so on), we will determine both the number of files and their cumulative size. The analysis will also report the total number of subdirectories discovered during the traversal.

In this implementation, we will parallelize the directory tree traversal itself. Each worker thread will process directories retrieved from a shared concurrent queue, discover any subdirectories they contain, and dynamically push them into the queue so that they can later be processed by any available worker. As a result, multiple threads will be able to explore different branches of the directory tree simultaneously while accumulating partial statistics that will ultimately be merged into a single global result.

PVS-Studio 8.00

by Valerii Filatov

From the article:

In the release, we have also expanded the list of C and C++ compilers that are compatible with the PVS-Studio analyzer for these languages. On Linux, the pvs-studio-analyzer utility supports the x86_64-pc-linux-gnu-c++ compiler. The TI C2000-CGT compiler is also supported on all platforms via compilation monitoring and tracing.

Andre Kostur - There’s a Hole in the C++ Type System

Abstract:

This is a story of identifying what I think is a hole in the C++ type system, describing a mitigation strategy, and starting the process of engaging the Committee with a change to the C++ language that would help users write the affected classes in a simpler and more intuitive way. With luck, this change may make it into C++29.

About the Speaker:

Andre Kostur has over 30 years of experience as a professional C++ developer, with a focus on designing and developing network solutions. As a young graduate he was responsible for introducing C++ to his employer; convincing them to take a chance on a language that was still years away from initial standardization.
As a corporate champion of C++ as well as the founder and lead of multiple C++ user groups, Andre routinely presents on all things C++ from the basics to the latest developments. His speaking credits also include corporate presentations and appearing as a speaker at CPPCon.
Andre is a member of the Standards Council of Canada one of the Canadian representatives on the ISO C++ Committee; and an active member of the online C++ community.

Automated Unit Testing On-The-Cheap: Part 2

by Chuck Allison

From the article:

In Part 1 of this two-part series I introduced a time-tested (i.e., old ) technique that handled automated unit testing in a remarkably simple way, including validating proper exception handling. The previous post left two problems on the table, however, and the journey to fix them turns out to be a nice tour of two key features of modern C++: inline variables and modules.

The simplicity of the test framework discussed in Part 1 follows from everything being contained in a small header file, test.h (include guards not shown):

Registration is now open for CppCon 2026!

CMake: Making Hard Things Easy

Wednesday, September 16, 2026 16:45 - 17:45 MDT

by Bill Hoffman

Summary of the talk:

Modern C++ development involves much more than compiling source files. Cross-platform builds, dependency management, C++ modules, package metadata, SBOM generation, CI infrastructure, and distributed builds have all increased the complexity of software engineering over the last two decades.

CMake has evolved alongside those challenges.

This talk explores how modern CMake helps make difficult software-engineering problems more manageable through targets, dependency modeling, metadata generation, debugging tools, and scalable build orchestration.

We will examine how CMake supports C++20 modules, including dynamic dependency scanning, build graph updates, and import std.

We will also look at CPS and SBOM generation together: CPS provides machine-readable package metadata, while SBOM support helps CMake expose software supply-chain information from the dependency graph.

Next, we will discuss debugging CMake itself using the CMake debugger protocol, and debugging builds using the CMake Instrumentation API to understand where time is spent during configuration and build execution.

Finally, we will examine distributed execution and build acceleration, exploring options available to CMake users in both open-source and commercial environments.

Along the way, we will discuss the real-world challenges, trade-offs, and lessons learned from evolving a long-lived build system to meet the demands of modern C++ development.

This is not your mother’s CMake.

Trip report: ACCU On Sea 2026

by Sandor Dargo

From the article:

he venue is the same as C++ On Sea, many organisers are the same, but of course there are also changes. The conference chair is no longer Phil Nash but Guy Davidson. The schedule is more packed — this year, the conference ran over four days (ignoring the two workshop days), including Saturday. Probably due to the fact that these two major C++ conferences were merged, I think there were more people than ever — around 400 C++ enthusiasts. It was sold out.

And yet, in general, familiar faces. This place holds a special place in my heart as it was the first in-person international C++ conference which I attended as a speaker.

In this post I’ll share:

• Highlights from talks and ideas that resonated with me.
• Personal impressions, including reflections on my own sessions — both the main talk and the lightning talk.

I’ll update this article with links to the recordings as soon as they become available.

Registration is now open for CppCon 2026!

AI is UB with Better PR

Wednesday, September 16, 2026 15:15 - 16:15 MDT

by Matt Kulukundis & Andy Soffer

Summary of the talk:

C++ runs the world’s systems, and with that comes a responsibility for safety and stability. Avoiding AI entirely gives up on incredible potential benefits, but using AI without guardrails poses significant risks to our critical systems. How does AI fit into this world? This talk examines effective and ineffective approaches to using AI in systems that cannot afford “slop.” We will explore several case studies where AI produced significant value in C++, and several where it did not. The pattern that emerges is consistent: AI thrives when it is orchestrating well-defined, deterministic components, translating between them intelligently without being trusted to reason correctly on its own. When AI is asked to be the system rather than connect the system, things fall apart.

Registration is now open for CppCon 2026!

In Pursuit of a 6,000 FPS Game Boy Emulator

Wednesday, September 16, 2026 14:00 - 15:00 MDT

by Tom Tesch

Summary of the talk:

How far can modern C++ push an emulator before performance stops being a C++ problem and becomes a systems problem? This talk is the final part of a CppCon trilogy about building an extremely fast Game Boy emulator in modern C++, moving from high-performance emulation techniques to the limits imposed by hardware, compilers, and CPU architecture.

The target is intentionally absurd but not arbitrary: a Game Boy emulator running Tetris at roughly 100 times original speed, about 6,000 frames per second. However, the goal is not to support every Game Boy cartridge ever made. This project deliberately specializes for one iconic game first, using the code paths Tetris actually exercises as a guide, while keeping enough design discipline to test other games later. That means questioning the architecture of the emulator itself: instruction dispatch, memory access, generated code size, cache behavior, branch prediction, compile-time computation, benchmarking methodology, and the tension between accuracy, maintainability, flexibility, and raw throughput.

This is not a victory-lap performance talk. It is a measurement-driven engineering investigation. Rather than treating 6,000 FPS as just a headline number, this talk treats it as a stress test: a way to force difficult design decisions into the open. Attendees will leave with concrete lessons about performance-oriented C++: how to measure methodically, how to specialize without losing control, how to reason about modern CPU behavior, and how to decide when an optimization is worth its cost.

Dispatch Table with C++26 Reflection - Zero Boilerplate & Zero Runtime Overhead

by NoqtaBeda

From the article:

As compile-time reflection is finally adopted to C++26 standard, developers are enabled to fetch and operate on the metadata of the C++ program itself. Metadata of various C++ entities (variables, functions, classes, templates, namespaces, etc.) can be obtained from reflection API in C++26 standard library, the most frequently used of which is getting an entity’s name, type, list of members or list of base classes. Reflection is incredibly helpful to support more elegant and more efficient C++ code by utilizing the metadata properly. In this blog we dive into dispatch table, which is a common pattern in real-world C++ code, demonstrating how the great power and expressiveness of C++26 reflection helps with eliminating boilerplate code and runtime overhead that are inevitable in pre-C++26 dispatch table implementation, and then, how the API design of our reflection-based dispatch table can be further improved step-by-step.

The contents shown by this blog has full implementation in my rbox library. Source code is available in GitHub.

How It Works Finally

We start from the following example to demonstrate the expressiveness of C++26 reflection. All the constexpr evaluations of building the dispatch_table are encapsulated into the API macro RBOX_FUNCTION_FIXED_MAP. The first parameter ops is the namespace whose members are to be traversed. The second parameter "do_*" is the identifier pattern which the members of namespace ops are expected to follow. Each function in namespace ops is added to the dispatch table if and only if its identifier matches the pattern "do_*". The dispatch_table returned is an associative array whose value type is auto-deduced as int (*)(int, int) and the internal data structure is selected adaptively according to the input (typically a hash table, or a linear table as fallback when the number of entries is few).

Registration is now open for CppCon 2026!

Awaiters and Awaitables

Wednesday, September 16, 2026 09:00 - 10:00 MDT

by Mateusz Pusz

Summary of the talk:

C++20 coroutines come with a reputation for complexity — and writing your own coroutine return type deserves that reputation. But here is the good news: you probably don't have to. With std::generator in C++23, high-quality libraries like Asio and cppcoro today, and std::task on its way in C++26, most developers can simply write co_await and move on.

There is one gap, however. Sooner or later, every developer using coroutines needs to bridge an existing asynchronous interface — a timer, an I/O operation, a thread pool callback, a legacy future — into the coroutine world. That bridge is built with awaiters and awaitables, and that is exactly what this session teaches.

We will start from first principles: what does co await actually do? We will demystify the three functions that form the awaiter protocol — await ready, await suspend, and await resume — and build a clear mental model for each. We will implement a real awaiter from scratch, then explore how symmetric control transfer keeps the call stack flat across deeply chained async operations. Next, we will learn how to make any existing type co await-able without modifying it, using operator co await, and how await transform lets you restrict or adapt awaitable behavior to a specific coroutine context. Finally, we will look at how to write cancellation-aware awaiters using std::stop token, so your coroutines respond promptly when work is no longer needed.

No prior coroutines experience is assumed. If you know what co await looks like on the surface but not what happens underneath it, this session is for you. You will leave with both the knowledge and the code to wrap any asynchronous operation into a first-class co await expression.

Book Review: Memory Management in C++ by Patrice Roy

by Sandor Dargo

From the article:

What impressed me right away is how current the book is. It discusses erroneous behaviour, which is something that was only introduced in C++26. It also proposes the usage of deducing this as a way to reduce boilerplate in begin()/end() implementations. Finding a book that is both thorough in its foundations and aware of the latest developments is rare.

As Patrice writes, “C++ is powerful and flexible, but if you program in C++, you’re expected to behave responsibly and professionally.” This sentence sets the tone for the whole book. It’s not about dumbing things down or hiding complexity behind abstractions. It’s about understanding your tools well enough to use them correctly.

Let me highlight three ideas from the book that I found particularly valuable.

char* is not what you think it is

One of the most eye-opening sections deals with the true meaning of char*. Most of us think of char as a character type. But as Patrice explains, “char* means ‘pointer to a byte.’ Due to the C language roots of C++, a char* can alias any address in memory (the char type, regardless of its name, which evocates ‘character’, really means ‘byte’ in C and, by extension, in C++).”

This is not just a historical curiosity. It has real consequences for optimizations. “There is an ongoing effort in C++ to give char the meaning of ‘character,’ but as of this writing, a char* can alias pretty much anything in a program. This hampers some compiler optimization opportunities (it is hard to constrain or reason about something that can lead to literally anything in memory).”

Deriving Type Erasure

by David Álvarez Rosa

From the article:

Ever looked at std::any and wondered what’s going on behind the scenes? Beneath the intimidating interface is a classic technique called type erasure: concrete types hidden behind a small, uniform wrapper.

Starting from familiar tools like virtual functions and templates, we’ll build a minimal std::any. By the end, you’ll have a clear understanding of how type erasure works under the hood.

Registration is now open for CppCon 2026!

What Are We Synchronizing?

Tuesday, September 15, 2026 14:00 - 15:00 MDT

by Robert Leahy

Summary of the talk:

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.

Parsing JSON at compile time with C++26 static reflection

by Daniel Lemire

From the article:

Suppose that you have a configuration file in JSON. Something like this:

{ "width": 1920, "height": 1080, "fullscreen": true, 
"title": "My Game", "volume": 0.8 } 

Normally you ship this file alongside your program, open it at startup, read it, and parse it. That is a lot of work for data that never changes. What if the file is fixed at build time? Could the compiler read it, parse it, and bake the result directly into the executable as a constant?

With C++26, the answer is yes. We need two new ingredients, all of which are usable right now with the latest version of the GCC compiler (16).

1. #embed to pull the file into the program at compile time,
2. A software library supporting static reflection like simdjson.

Let me show you how far we can take this.

Registration is now open for CppCon 2026!

Processor Design and C++ Memory Models

Tuesday, September 15, 2026 09:00 - 10:00 MDT

by Ofek Shilon

Summary of the talk:

std::atomic and std::memory_order are utterly opaque abstractions. It feels like they were put in place to hide some monstrosity that is too complex for mortals to comprehend, and inevitably when trying to understand the underlying reality, the explanations end with 'the processor does weird things' and 'think about it as if...'.

Well, 'think about it as if' no more. In this talk we'll present the gory and wonderful mechanics of cache coherence protocols, store buffers, cache invalidation queues and the in-processor load-store-queue. We'll explain how modern hardware design makes different cores have different views of memory, and what fences and read-modify-write instructions do exactly - for both x86/64 and ARM/RISC-V (which are sometimes dramatically different).

This is an advanced low-level talk located at the borderline of software development and electrical engineering, discussing topics rarely - if ever - discussed at C++ conference talks.

C++26: Cleaning up string literals

by Sandor Dargo

From the article:

Not all string literals in C++ end up in your compiled program. Some are used exclusively at compile time — the compiler reads them, acts on them, and then they’re gone. They never make it into the binary.

These strings appear in the following contexts:

• _Pragma directives
• #line directives
• [[nodiscard]] and [[deprecated]] attributes
• extern linkage specifications
• asm statements
• static_assert messages
• Literal operator names

Since these strings are never evaluated at runtime, they don’t need to be converted to the execution encoding or any encoding specified by a prefix like L, u8, u, or U. Despite this, before C++26, the standard didn’t formally distinguish them from regular string literals. Compilers handled them inconsistently.

 

Registration is now open for CppCon 2026!

The Journey to "/W4 /WX": How Hard Could It Be?

Monday, September 14, 2026 15:15 - 16:15 MDT

by Keith Stockdale

Summary of the talk:

Building on the recent work of improving the quality of Sea of Thieves' codebase by upgrading from C++14 to C++20, this talk will focus on the work that has went into enabling warnings as errors on the game, and more.

Rare will discuss the motivations behind wanting to crank up the warning level, and to flick the "warnings as errors" switch after 10 years of development in their multi-million line Unreal Engine code base.

What were the challenges? How much effort did it take? Was it worth it? Did we find any bugs? Did we stop at just "/W4 /WX"? What warnings did we find the most useful? What warnings were deemed unhelpful? All of these questions and probably more will be answered throughout this session.

A Coalescing Event Queue for High-Frequency Systems

by Ajay Pandey

From the article:

High-frequency event-driven systems often ingest more updates than downstream components can usefully process. A conventional FIFO queue preserves every event, but that can be the wrong abstraction when the consumer ultimately needs a current view of state rather than a complete history of every intermediate transition. This article describes a coalescing event queue: a design pattern that buffers events over short, bounded time windows and applies explicit merge policies to reduce redundant updates while preserving the most relevant state. The design uses a multi-producer, single-consumer concurrency model, key-based coalescing, policy-driven merge rules, and a decoupled dispatch layer. A C++ sketch illustrates how the queue can be implemented with clear ownership, bounded synchronization, and extensible merge semantics.

The problem with treating every event equally

Many systems are built around the assumption that every event should be queued, preserved, and processed in arrival order. That is a reasonable default for audit trails, ledgers, command streams, transactional pipelines, and any workflow where the complete sequence is semantically important.

It is not always the right default.

Registration is now open for CppCon 2026!

Towards a Complete Contract-Assertion Facility for C++

Monday, September 14, 2026 14:00 - 15:00 MDT

by Timur Doumler

Summary of the talk:

C++26 introduces contract assertions: language-level constructs for expressing expectations about program correctness, optionally checking them at runtime, and configuring how violations are handled. However, what ships in C++26 is intentionally minimal — not the final destination, but a carefully designed foundation for a much more capable facility.

In this talk, we begin with a brief overview of contract assertions as they exist in C++26, including the three kinds of assertions ( pre , post , and contract_assert ), the four evaluation semantics ( ignore , observe , enforce , and quick-enforce ), and the user-replaceable contract-violation handler. The focus of the talk, however, is the next stage of evolution already underway.

We will explore the major extensions currently planned for C++29 and beyond, and the problems they are intended to address, and how they build upon the extensibility intentionally designed into the C++26 facility. Many of the concerns raised during standardisation — particularly around scalability, configurability, and expressiveness — are already being addressed by these extensions. We will discuss contract assertions on virtual functions; grouping contract assertions and configuring evaluation semantics by group; constraining evaluation semantics (for example, assertions that must always or never be enforced); postconditions that refer to earlier program state; user-defined diagnostic messages; and finally, compiler-generated, implicit contract assertions guarding against core-language undefined behavior. We then look even further ahead at more ambitious ideas still in earlier stages of exploration: class invariants, contracts on function pointers, and procedural interfaces.

Rather than just listing the proposed extensions, we will examine the design considerations behind them and show how the new functionality fits into the broader model of contract assertions in C++. What does it mean for contracts to participate in virtual dispatch? When can contract assertions support optimisation? How can evaluation semantics remain both predictable and configurable across large codebases? Understanding these questions is essential to understanding where contract assertions in C++ are heading next.

This talk is intended for anyone interested not only in how contract assertions work in C++, but also in the principles shaping their future evolution — and what a complete contract facility for C++ might ultimately look like.

C++ Reflection: a Universal Printer

by Lieven de Cock

From the article:

The challenge of this article is to write a universal printer/formatter, so that we can format (nearly) any type we have. By that we mean print out the values (and names) of all its members, including the members of base classes.

Let’s get started.

The Lift operator

The first thing we need to do is move from the code domain to the reflection domain, and that is done by applying the ‘lift operator’ (^^) to a specific type.

Say we have a type Coordinate:

  struct Coordinate
  {
    int x{10};
    int y{20]:
    int z{30};
  };

Let’s reflect on it with ^^Coordinate. This gives us an object of type std::meta::info, and this contains a lot of information we can inspect by calling several inspection/reflection methods.

Registration is now open for CppCon 2026!

Back to Basics: Move Semantics

Monday, September 14, 2026 11:00 - 12:00 MDT

by Ruslan Arutyunyan

Summary of the talk:

Move semantics and perfect forwarding, introduced in C++11, are quite impactful features that still remain a source of confusion even for some experienced developers. This talk builds understanding from the ground up: what problem move semantics solves, how rvalue references enable it, and why the rules work the way they do.

We start with the cost of unnecessary copies and how move constructors and move assignment operators let us transfer resources instead of duplicating them. We then look at how std::move doesn't actually move anything — and what it really does. From there we tackle the forwarding problem: why writing a single function that preserves the value category of its arguments is necessary, how forwarding references (also known as "universal reference" in the past) solve it, and what std::forward does under the hood.

Along the way we cover the practical details that trip people up: reference collapsing rules, the interaction between overload resolution and reference binding, when the compiler generates move operations and when it doesn't, and the cases where std::move can actually pessimize your code. We also discuss trade-offs in parameter passing — by value, by const reference, or by forwarding reference — so attendees should have a clearer model for making these decisions in their own code.

At the end we will look into std::forward_like and explore how it is different from std::forward .

No prior knowledge of rvalue references is assumed. Familiarity with copy constructors, destructors, and basic templates is helpful.

Rotation revisited: Avoiding having to calculate the gcd when doing cycle decomposition

by Raymond Chen

From the article:

The trick is realizing that the total number of elements is equal to the sum of the lengths of each of its cycles, and each of the initial elements belongs to a different cycle. Therefore, we can just keep rotating elements until the number of elements rotated is equal to the total. We don’t have to precalculate the number of cycles; we just let the counter tell us when we’re done.

auto a = std::distance(first, mid); // number of "A" elements
auto n = std::distance(first, last); // total elements
auto count = 0;
auto k = 0;

while (count < n) {
    // Rotate the elements in the cycle starting at k
    auto save = std::move(first[k]);
    auto i, next = k;
    while (i = next, next = (i + a) % n, next != k) {
        first[i] = std::move(first[next]);
        ++count;
    }
    first[i] = std::move(save);
    ++count;
}

Phil Nash - Contemporary C++ Testing

Abstract:

It's been 15 years since Catch claimed to be a "Modern C++ Testing framework". C++ has been through some game changing stages of evolution in that time. What would a test framework built for the C++ of today look like?

About the Speaker:

Phil is the original author of the C++ test framework, Catch2 and other open source libraries.
A Senior Software Engineer at Bloomberg he has had a career that spans finance, mobile and software security, with a diversion into Developer Advocacy at JetBrains and Sonar.
He's also a member of the ISO C++ standards committee, organiser of C++ London and ACCU on Sea (the merging of the ACCU conference with C++ on Sea), as well as former co-host and producer of CppCast, cpp.chat and No Diagnostic Required.

Elements of Concurrency

by Lucian Radu Teodorescu

From the article:

I’ve long been attracted to a quote often attributed to Einstein (whether or not he said it, it’s good advice):

Everything should be made as simple as possible, but no simpler.

I take it as a guiding principle for intellectual work on subjects with high inherent complexity. Software is one such subject; Brooks famously called it essential complexity [Brooks95]. Moreover, concurrency is one of the sharpest edges of that complexity.

I have been writing about concurrency in Overload for years, but those articles were mostly practical: tutorials, patterns, pitfalls, and implementation techniques. Here I want to step back and talk about the essence of concurrency.

I will build on the work of Tony Hoare and collaborators on the laws of programming with concurrency [Hoare09, Hoare11, Hoare13, Hoare15] (the talks are particularly enjoyable). I’ll also borrow Leslie Lamport’s viewpoint that concurrency is about the ordering of events as presented in the ‘Time, clocks, and the ordering of events in a distributed system’ article [Lamport78].

The central thesis of this article is simple: Concurrency is strict partial ordering.

Once you start seeing programs as collections of work items related by a strict partial order <, much of the apparent complexity becomes a matter of making ordering constraints explicit, manipulating them algebraically, and choosing implementations that respect them.

Some parts are a bit formal, but the payoff is a shift in perspective. Rather than treating concurrency as a bag of mechanisms (threads, locks, async, executors), we treat those mechanisms as different ways of expressing and enforcing the same ordering structure.

Rotation revisited: Cycle decomposition in clang’s libcxx

by Raymond Chen

From the article:

The implementation in clang’s libcxx performs the minimum number of swaps, roughly n/2, where n is the total number of elements. It does so by viewing the rotation as a permutation and walking through each of the cycles.

For notational convenience, let a be |A| and n be |A| + |B| (the total number of elements). The number of cycles is gcd(a, b), and the k‘th cycle consists of the elements starting at first + k, and then stepping to the next element by moving forward another a elements, with wraparound, until you return back to the starting point.

For example, if you have |A| = 4 and |B| = 6, then the cycle that starts at A1 takes 4 steps forward to continues to B1; takes another 4 steps forward to B5; then takes 2 steps forward, wraps around, and then two more steps forward, landing on A3; then takes 4 steps forward to B3; and then takes 4 steps forward and wraps around to A1, which is the starting point.

Bryce Adelstein Lelbach - The CUDA C++ Developer's Toolbox

Abstract:

Getting the most out of your GPU with C++ doesn't require writing custom kernels or manually managing storage for everything! Come learn about the libraries and techniques that make writing CUDA C++ code easier and more performant. Through examples, we'll explore all aspects of writing modern C++ software for GPUs, including heterogeneous memory management, algorithm design, and synchronization. During this talk, you'll:

• Learn to evaluate when you should use a CUDA library versus writing your own kernel.
• Explore popular CUDA C++ libraries such as Thrust, CUB, and libcu++.
• Understand how you can easily compose different CUDA libraries and your own custom CUDA C++ code together.
• Build intuition about the performance implications of CUDA libraries.
• You'll leave confident about how to select the best tool for the job to accelerate your C++ applications for your unique use cases.

 

About the Speaker:

Bryce Adelstein Lelbach has spent over a decade developing programming languages, compilers, and libraries. He is passionate about parallel programming and strives to make it more accessible for everyone.
Bryce is a Principal Architect at NVIDIA, where he founded the Core C++ Compute Libraries team and now leads the Vanguard Programming group that drives NVIDIA's roadmap for programming languages, compilers, and core libraries.
He is a leader of the systems programming language community, having served as chair of the C++ Library Evolution and the US programming language standards committee. He has been an organizer and program chair for many conferences over the years. On the C++ committee, he has worked on concurrency primitives, parallel algorithms, senders, and multidimensional arrays.
He previously worked at Lawrence Berkeley National Laboratory and Louisiana State University. He is one of the founding developers of the HPX parallel runtime system. Outside of work, Bryce is passionate about airplanes and watches. He lives in Midtown Manhattan with his girlfriend and dog.

Pure Virtual C++ 2026 Is a Wrap

by Marian Luparu

From the article:

Missed a session, or want to rewatch? All talks, both the live broadcast featured sessions and the on-demand sessions, are available now. Watch the full playlist on YouTube.

Featured sessions

These were introduced live during the broadcast, in this order:

• C++ semantic awareness in the CLI: From Project Load to Code Change — Sinem Akinci
• Mind The Gap: C++/Rust Interop — Victor Ciura
• From Completions to Agents: AI-Driven C++ in Visual Studio — Augustin Popa
• Cut Your Build Times Without Becoming a Build Expert — David Li
• C++/WinRT: Build faster and smaller with C++20 modules — Ryan Shepherd

Rotation revisited: A shocking discovery about gcc’s unidirectional rotation algorithm

by Raymond Chen

From the article:

As with all shocking discoveries, this one will shock disappoint you.

The discovery is that the gcc libstdc++ algorithm is the same as the forward-iterator algorithm!

Let’s run both algorithms on a problem where the two blocks are A1, A2, A3, B1, B2, B3, B4, B5. I’ll put the old forward iterator algorithm on top and the new gcc libstdc++ algorithm below.

first			mid					last
↓			↓					↓
A1	A2	A3	B1	B2	B3	B4	B5
↑			↑					↑
first			mid					last

 

We swap at first and mid, then advance both pointers. The two algorithms agree until first reaches the end of the original A block.

			first			mid		last
			↓			↓		↓
B1	B2	B3	A1	A2	A3	B4	B5
			↑			↑		↑
			first			mid		last

 

The old algorithm recurses in order to exchange A1, A2, A3 with B4, B4. This happens by exchanging A1 with B4 and A2 with B5.

Write, shorten, optimize

by Andrey Karpov

From the article:

Let's see how these implementations compare in reality. Designing a fair benchmark took a bit of effort. First, I had to ensure the input data couldn't overflow a 64-bit signed integer, since signed overflow is undefined behavior and would invalidate the measurements. Second, to make the contest fair, the test cases alternated between arrays with and without zero elements. Finally, the input arrays had varying lengths.

I'm not claiming that the measurements are rigorous, but they represent a general idea. The speed of the first original algorithm is taken as the baseline. I used Clang with the -O2 and -m64 options. The original version with two loops: 1. My version with a single loop: 0.88. The Claude version with a single multiplication: 0.92.

Rotation revisited: Another unidirectional algorithm

by Raymond Chen

From the article:

Some time ago, we looked at the problem of swapping two blocks of memory that reside inside a larger block, in constant memory, and along the way, we learned about std::rotate which swaps two adjacent blocks of memory (not necessarily the same size).

I noted in a postscript that clang’s libcxx and gcc’s libstdc++ contain specializations of std::rotate for random-access iterators that view the operation as a permutation and decomposes the permutation into cycles.

I was mistaken.

The implementation in gcc’s libstdc++ has special cases for single-element rotations, but in the general case, it uses a different algorithm.

Let’s call the blocks of memory to be exchanged A and B, where A is made up of elements A1, A2, A3, and so on; and block B has elements B1, B2, B3, and so on. Without loss of generality, suppose the A block is smaller. (If not, we can just mirror the algorithm.) And for concreteness let’s say that the elements are A1, A2, A3, B1, B2, B3, B4, B5.

C++ More C++26 reflection at compile-time

by Andreas Fertig

From the article:

One of the great things about reflection is that we can already explore the new feature since with Clang there is a compiler available that implements all the facets.

I was again exploring what of my use cases would be better solved with reflection. Now, one thing that I had to do most of my career is reading and writing data coming from a network connection. The definition of network was different at different times. What was common is, that everything going out was sent in network byte order (big-endian), and the everything that was received arrived in network byte order as well. For some systems there was no difference, as they where already big endian machines. But not all the time. Especially ARM pushed little endian. For a subset of the systems data had to be byte-swapped when it was received or sent.

How to swap data?

The issue here (was) is, how to swap the data? Every data type larger than a byte must be swapped every time. C++23 gave us std::byteswap which removes the need for the POSIX functions like htons. At least an improvement in terms of safety.

C++26 - Enter Static Reflection

by Keith Stockdale

From the article:

Step 0: Figuring out how to even use reflection?!

As I mentioned, I had never used C++26 reflection, and I genuinely didn’t know how to even engage with it. I found CppReference to be quite lacking right now…

I am sure that will change as time goes on, but for right now, it’s a bit rubbish. So I found myself leaning on two other sources of information:

1. The standard: Specifically Header synopsis. This was pretty damn great for just being able to find my way around all the facilities available. There are links to all the descriptions of what each facility does and what the expected behaviour is.
2. Barry Revzin’s blog: Barry’s blog has some absolutely brilliant content around reflection, and I can’t recommend it enough.

C++26: More function wrappers

by Sandor Dargo

From the article:

C++26 continues to fill the gaps in our type-erased callable wrapper story. We already had std::function since C++11 and std::move_only_function since C++23, but there were still missing pieces. Now we’re getting two new additions: std::copyable_function and std::function_ref.

What’s wrong with std::function?

std::function has served us well, but it has two well-known issues. First, it can add significantly to binary size. Second, and more fundamentally, it has a const-correctness defect. 

C++26: Standard library hardening

by Sandor Dargo

From the article:

Undefined behavior (UB) in C++ is one of the hardest categories of bugs to deal with. It can silently corrupt memory, cause crashes far from the actual mistake, or — worst of all — just happens to work on your machine. A significant share of UB in real codebases comes not from exotic language features, but from basic misuse of the standard library: accessing a vector out of bounds, calling front() on an empty container, or dereferencing an empty optional.

C++26 addresses this directly with standard library hardening, introduced via P3471R4.

What is library hardening?

Library hardening converts certain undefined behavior in the standard library into detectable contract violations at runtime. When a hardened precondition is violated, the runtime reacts before any other observable side effect — think of it as adding bounds checking to operations that are UB today.

This is not a new idea. All three major standard library implementations already ship vendor-specific hardening modes. The problem is that these mechanisms are all different, non-portable, and inconsistently specified. P3471R4 standardizes what implementations already do.

The standardized version of hardening becomes the first use of contracts (specified in P2900). This aligns perfectly with the direction of the language.

Guy Davidson - Abstraction: The True Superpower of C++

Abstract:

The word "abstraction" is used extensively when discussing the facilities of C++. But what does it actually mean? Can you spot an abstraction when you see one? Can you spot the correct level of abstraction? Can you spot what is being abstracted? And what does a zero-cost abstraction mean? All these questions and more will be answered in this talk.

About the Speaker:

Guy Davidson is the convenor of the C++ standards committee. He is also the Head of Engineering at Six Impossible Things Before Breakfast. He has been writing games for nearly 50 years, having spent about half that time at Creative Assembly as the Head of Engineering Practice on the Total War franchise. He is the co-author of Beautiful C++, and you can find many of his talks online. In his copious free time, he plays the piano as well as singing first bass for the Brighton Festival Chorus. He lives in Brighton where he went to the University of Sussex back in the 80s.

From Undefined to Defined: Using std::launder in C++

by Andreas Fertig

From the article:

The fields where you can apply today's learning vary. The embedded domain is usually one where std::launder is used, but if you're writing library code, laundering occurs as well.

When things may break

I'm using the example from the paper P0532R0:

struct X {
  const int n;  A
  double    d;
};

X* p = new X{7, 8.8};  B

new(p) X{42, 9.9};  C

int  i = p->n;  D
auto d = p->d;  E

You're looking at several different pieces that need to come together. Notice that the struct X declares the member n as const.

Next, with the help of new, an object is created in B and the resulting pointer is stored in p. So far, so good.

The interesting part starts next in C with the placement new. If you've never done this, great, then you might not need to do the laundry, at least not in your C++ code.