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

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.

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.

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.

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):

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.

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).

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.

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.

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.

 

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.

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.

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;
}

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.

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.

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.

Upcoming C++ User Group Meetings in July 2026

by Jens Weller

From the article:

July hosts again quite a few C++ User Groups, next Thursday Meeting C++ is celebrating its 14th birthday with a talk on C++ User Groups: 14 Years of Meeting C++ - celebrating with C++ User Groups at Meeting C++.

In since mid June the next weekly meetings are also included into the Meeting C++ blogroll.

 

Automated Unit Testing On-The-Cheap: Part 1

by Chuck Allison

From the article:

When Extreme Programming was all the rage in the late 1990s, automated unit testing was still a relatively fresh idea for many working software developers. JUnit and CppUnit emerged as the leading test frameworks for Java and C++, but I wanted something even simpler—code that students could understand and that was easy to use.

I thought I’d achieved it in the well-received article I wrote for the C/C++ Users journal in September 2000, The Simplest Automated Unit Test Framework That Could Possibly Work.

But I was wrong.

Silent foe or quiet ally: Brief guide to alignment in C++. Part 3

by Elizaveta Zhegalova

From the article:

So far, we've treated an object as a static, rigidly determined data structure. Every field address was known at compile time, and inheritance simply layered parent and child attributes. Alas, object-oriented programming is impossible without dynamic polymorphism, which is implemented in C++ via the RTTI mechanism and virtual functions.

 

What is virtuality?

Let me start from an off-topic question. How does the compiler know which piece of machine code to execute at a specific line in your program? Answering this question will help us understand what virtuality really means.

 

Imagine we write object.print(). For the processor, it's not an abstract action but a command to jump to a certain address in memory with some function instructions. But where do we take that address from?

 

During compilation, each code line becomes one or more machine instructions, each receives a unique sequential address in memory. The same applies to functions. A compiler translates them into machine code and assigns the next available address. Stitching a function call in code to its actual memory address is called binding.

 

Depending on when the call address is bound to the function address, there are two scenarios.

 

1. Static/early binding.

 

By default, static (early) binding is used. A compiler rigidly "hardwires" a specific function address at the call place in code during compilation. This decision relies solely on the pointer or reference type, not the actual object in memory. For instance, when a compiler sees a Base* pointer, it chooses the method address from the base class. It's fast and requires no additional evaluations. So, the jump goes to an already known address. It's also efficient, but it makes the program inflexible at runtime.

C++23 - The Complete Guide

by Nicolai Josuttis

So far, the book has 350 pages and is not complete yet. However, many C++23 features are covered already. For details of the current content, look at www.cppstd23.com. There you can also find several example programs demonstrating how all the new features can be used.

You can order the book at leanpub.com/cpp23 for a reduced price and will get all updates for free. This way, you have early access to details of the new features and I have early income and can process feedback from you for the final version, which will also be available as hardcover (not included).

I hope it helps. Enjoy!

 

C++26: string and string_view improvements

by Sandor Dargo

From the article:

But let’s start with a brief reminder of what a string_view is.

Reminder: the role of string_view

std::string_view was introduced in C++17 and its purpose is to provide read-only access to a string-like object. It can often replace const string& parameters and offers a significant performance gain. It’s generally advisable to use it whenever you’d pass an immutable string-like input that you cannot move from source to target.

We covered the topic earlier in more depth here.

P2495R3: Interfacing stringstreams with string_view

A stringstream is a good old tool for dealing with operations on string-based streams. While C++23 introduced spanstreams, due to fundamental semantic differences, stringstreams are not dead and it’s important to maintain them.

Being a good old tool also means they predate string_view. Given the available set of constructors, if you want to initialize a stringstream from a string_view, you first have to manually convert it into a string.

P2495R3 fixes this by adding new constructors accepting string_views.

It’s worth noting that this is a purely additive library change — it doesn’t break existing code.

At the moment of publication, this change is already available on Clang 19.

New features in GCC 16: Improved error messages and SARIF output

by David Malcolm

From the article:

A well-known challenge for C++ developers is the readability of template-related error messages. C++ compilers tend to either provide too little information or spew screenfuls of text at you. Either way, the errors can be difficult to decipher.

GCC error messages have a hierarchical structure to them. In GCC 15, I added an experimental option that shows this structure as a collection of nested bullet points.

In GCC 16, this behavior is now the default. You can return to the previous behavior using -fno-diagnostics-show-nesting or -fdiagnostics-plain-output. I fixed several bugs and made use of the hierarchical structure in more places. For example, it is easy to get declarations and definitions out of sync when manually adding const to a parameter:

class foo

{

  public:

    void test(int i, int j, void *ptr, int k);

};

    

// Wrong "const"-ness of param 3.

void foo::test(int i, int j, const void *ptr, int k)

{

}

C++26: Structured Bindings can introduce a Pack

by Sandor Dargo

From the article:

Before diving into the feature itself, let’s briefly clarify what a pack is. A reasonably accurate (and not overly simplistic) definition is the following:

A parameter pack is a language construct that represents an arbitrary number of types or values, allowing code to accept and operate on an arbitrary number of arguments in a type-safe way.

I deliberately avoided using the word template in this definition. Historically, packs only existed in templated contexts, but that limitation is slowly being relaxed. Earlier versions of the proposal behind this feature even aimed to support structured binding packs in non-templated contexts. That part was eventually dropped due to implementation complexity and related objections — but the direction is still telling.

Annotations for C++26 Hashing

by Krystian Piękoś

From the article:

In my recent post, I demonstrated how to use static reflection from C++26 to implement generic hash computation for custom types. Let's review the final implementation. The core of the solution is the calculate_hash() function, which iterates over sub-objects (including both base classes sub-objects and class/struct non-static data members) to compute a combined hash.

template <typename T>
concept Hashable = requires {
  { std::hash<T>{}(std::declval<T>()) } -> std::convertible_to<size_t>;
};

template <typename T>
  requires std::is_class_v<T>
size_t calculate_hash(const T& obj, size_t seed = 0)
{
  constexpr auto ctx = std::meta::access_context::unchecked();

 
  static constexpr auto r_subobjects = std::define_static_array(std::meta::subobjects_of(^^T, ctx));

  template for (constexpr auto r_sub : r_subobjects)
  {
    using Subobject_t = typename[:std::meta::type_of(r_sub):];
    static_assert(Hashable<Subobject_t>, "Subobject must be hashable");
    Utility::hash_combine(seed, obj.[:r_sub:])
  }

  return seed;
}

How ref qualifiers led to deducing this

by Jens Weller

From the article:

Last week I shared an overview on ref qualifiers with you, this is a follow up on this post. Featuring deducing this, a C++23 feature that should be available in your compiler if its been released in 2025 or later.

Lets start with two more things you may want to know about ref qualifiers. First, const is also supported for the rvalue version: m::f()const && exists, though this is mostly not very useful. Thats why you rarely see it covered, as const rvalues are unusual to unvalid. But thats where m::f()const&&=delete comes in, it allows you to turn these object states in to compilation errors.

As ref qualifiers are also often used...

 

C++26: Structured Bindings in Conditions

by Sandor Dargo

From the article:

Structured bindings were introduced in C++17 as an alternative way of declaring variables. They allow you to decompose an object into a set of named variables, where the collection of those bindings conceptually represents the original object as a whole.

// https://godbolt.org/z/97GaMajMP

#include <cassert> #include <string> 
struct MyStruct {
    int num;
    std::string text;

    bool operator==(const MyStruct&) const noexcept = default;
};

MyStruct foo() {
    return {42, "let's go"};
}

int main() {
    const auto& [n, t] = foo();
    MyStruct ms{n, t};
    assert(ms == foo());
    return 0;
}

Let the Compiler Check Your Units

by Wu Yongwei

From the article:

I recently came across a C++ standard proposal P3045 [P3045R7], which aims to add physical units to C++. Curious, I looked into the existing unit libraries and went down quite a rabbit hole.

Type safety and user-defined literals

Before exploring these libraries, I was already somewhat familiar with the idea of ‘type safety’. I was also aware that user-defined literals (UDLs) [CppReference-1] allow creating literals of specific types with ease. Typical uses in the standard library include string/string_view literals and the chrono library [CppReference-2], which make code both convenient and safe.

Figure 1 shows some simple examples.

auto msg = "Hello "s + user_name;
auto t1 = chrono::steady_clock::now();
this_thread::sleep_for(500ms);
auto t2 = chrono::steady_clock::now();
auto duration = t2 - t1;
auto what = t1 + t2;      // Can't compile
cout << duration / 1.0ms; // To double, in ms

Exploring ref qualifiers in C++

by Jens Weller

From the article:

Ref qualifiers are today an old C++11 feature, and recently I wanted to know more about them. Especially their potential use cases.

Thats a particular point with this feature, I've seen examples - but often without a compelling use case. This feature is a great way to achieve very specific things in C++...

 

In today's post, I will explain one of C++'s biggest pitfalls: reinterpret_cast. Another title for this post could be: This is not the cast you're looking for!

What reinterpret_cast doesn't do

Andreas Fertig

From the article:

My motivation for this blog post comes from multiple training classes I thought over the past several months and a couple of talks I gave. Since C++23, you have a new facility in the Standard Library: std::start_lifetime_as. When teaching class with a focus on embedded environments or presenting talks with such a focus, I started to add std::start_lifetime_as to the material. With an interesting outcome.

The feedback I get is roughly:

• why do I need std::start_lifetime_as, I already have reinterpret_cast?
• why can I use reinterpret_cast?

If you never heard of start_lifetime_as please consider reading my post, The correct way to do type punning in C++ - The second act.

What Happens When a Destructor Throws

by Sandor Dargo

From the article:

Recently I wrote about the importance of finding joy in our jobs on The Dev Ladder. Mastery and deep understanding are key elements in finding that joy, especially now that generating code is cheap and increasingly done better by AI than by us.

Then a memory surfaced. I frequently ask during interviews — as part of a code review exercise — what happens when a destructor throws. Way too many candidates, even those interviewing for senior positions, cannot answer the question. Most say it’s bad practice, but cannot explain why. Some say the program might terminate. Getting an elaborate answer is rare.

I’m not saying it’s a dealbreaker, but it definitely doesn’t help.

Let’s see what actually happens.

The role of a destructor

A destructor is the key to implementing the RAII idiom. RAII matters because after you acquire a resource, things might go south. A function might need to return early, or it might throw. Making sure resources are released is cumbersome, and the cleanest way to achieve it is to wrap both acquisition and release in an object that handles this automatically.

But what if the release itself is not successful?

Destructors have no return value, so error reporting is limited. Typical options include logging, storing error state, or (discouraged) throwing.

Why did I mark throwing an exception discouraged?

Evolving a Translation System with Reflection in C++

By GitHub user: friedkeenan
 

From the post:

Lately, I’ve been using C++26 reflection to create some crazy and cursed stuff. But even though I quite enjoy that work, it is as well quite far from the norm of what reflection is going to offer us in our everyday code.

Reflection is definitely not just that craziness, and so I want to present reflection in a more grounded environment, and in a way that will probably land as more typical usage as our codebases gradually come into contact with it.

So then, in this blogpost, I will be exploring a spectrum of options for how reflection can upgrade a translation system that I already use in one of my projects. We’ll look at where it’s at now without reflection, identify places in which reflection could plausibly help, and then explore a series of modifications we could make to soothe those problem points.

The purpose of looking at each of these options will not be to declare that one is clearly the best option or the one that makes the most sense, but rather to get a better feel for what could make sense to do, and whether some things are really worth the effort. We’re trying to gauge the benefits that reflection can bring to our code.

And who knows, even if one option is less appealing for this particular situation, maybe in a different situation it could be the perfect fit.

At its core, assert() exists to validate runtime conditions. If the given expression evaluates to false, the program aborts. I’m almost certain you’ve used it before — at work, in personal projects, or at the very least in examples and code snippets.

So what’s the problem?

C++26: A User-Friendly assert() macro

by Sandor Dargo

From the article:

assert() is a macro — and a slightly sneaky one at that. Its name is written in lowercase, so it doesn’t follow the usual SCREAMING_SNAKE_CASE convention we associate with macros. There’s a good chance you’ve been using it for years without ever thinking about its macro nature.

Macros, of course, aren’t particularly popular among modern C++ developers. But the issue here isn’t the usual - but valid - “macros are evil” argument. The real problem is more specific:

The preprocessor only understands parentheses for grouping. It does not understand other C++ syntax such as template angle brackets or brace-initialization.

As a result, several otherwise perfectly valid-looking assertions fail to compile:

// https://godbolt.org/z/9sqM7PvWh using Int = int; int x = 1, y = 2; assert(std::is_same<int, Int>::value); assert([x, y]() { return x < y; }() == 1); assert(std::vector<int>{1, 2, 3}.size() == 3);

 

In this article, we'll build a macro-base alternative that's more suitable for game development in ~200 lines of C++.

Stackless coroutines for gamedev in ~200 lines of C++

by Vittorio Romeo

From the article:

For a game I want a coroutine that is part of an object’s data. When the object dies, the coroutine dies with it. When I serialize the object to a save buffer, the coroutine’s state goes with it. When the optimizer is off, there is no extra cost compared to the equivalent state machine. C++20 coroutines do not provide any of these guarantees out of the box.

Let’s build something that does.

Glaze 7.2 - C++26 Reflection | YAML, CBOR, MessagePack, TOML and more

From the article:

Glaze now supports C++26 reflection with experimental GCC and Clang compilers. GCC 16 will soon be released with this support. When enabled, Glaze replaces the traditional __PRETTY_FUNCTION__ parsing and structured binding tricks with proper compile-time reflection primitives (std::meta).

The API doesn't change at all. You just get much more powerful automatic reflection that still works with Glaze overrides! Glaze was designed with automatic reflection in mind and still lets you customize reflection metadata using glz::meta on top of what std::meta provides via defaults.

Behold the power of meta::substitute

by Barry Revzin

From the article:

Over winter break, I started working on proposal for string interpolation. It was a lot of fun to work through implementing, basically an hour a day during my daughter’s nap time. The design itself is motivated by wanting to have a lot more functionality other than just formatting — and one of the examples in the paper was implementing an algorithm that does highlighting of the interpolations, such that:

 

 

 

would print this:

x=5 and y=*10* and z=hello!

without doing any additional parsing work. I got the example from Vittorio Romeo’s original paper.

Now, when I wrote the paper, I considered this to be a simple example demonstrating something that was possible with the design I was proposing that was not possible with the other design. I thought that because obviously you need the format string as a compile-time constant in order to parse it at compile time to get the information that you need.

Let's check vibe code that acts like optimized C++ one but is actually a mess

by Andrey Karpov

From the article:

Clearly, the 64-bit code is much more efficient, except when SSE2 is involved. Even then, though, everything runs quickly. The code Claude Opus generated for the markus project is the worst of all the options. Not only is the simplest implementation with a regular loop faster, it's also shorter. The extra code lines only made things worse.

Devirtualization and Static Polymorphism

by David Álvarez Rosa

From the article:

Ever wondered why your “clean” polymorphic design underperforms in benchmarks? Virtual dispatch enables polymorphism, but it comes with hidden overhead: pointer indirection, larger object layouts, and fewer inlining opportunities.

Compilers do their best to devirtualize these calls, but it isn’t always possible. On latency-sensitive paths, it’s beneficial to manually replace dynamic dispatch with static polymorphism, so calls are resolved at compile time and the abstraction has effectively zero runtime cost.

Power of C++26 Reflection: Strong (opaque) type definitions 

From the article:

With reflection, you can easily create "opaque" type definitions, i.e "strong types". It works by having an inner value stored, and wrapping over all public member functions.

Note: I am using queue_injection { ... } with the EDG experimental reflection, which afaik wasn't actually integrated into the C++26 standard, but without it you would simply need two build stages for codegen. This is also just a proof of concept, some features aren't fully developed (e.g aggregate initialization)

struct Item { /* ... */ }; // name, price as methods

struct FoodItem;
struct BookItem;
struct MovieItem;

consteval { 
    make_strong_typedef(^^FoodItem, ^^Item); 
    make_strong_typedef(^^BookItem, ^^Item); 
    make_strong_typedef(^^MovieItem, ^^Item); 
}

// Fully distinct types
void display(FoodItem &i) {
    std::cout << "Food: " << i.name() << ", " << i.price() << std::endl;
}
void display(BookItem &i) {
    std::cout << "Book: " << i.name() << ", " << i.price() << std::endl;
}

int main() {
    FoodItem fi("apple", 10); // works if Item constructor isn't marked explicit
    FoodItem fi_conversion(Item{"chocolate", 5}); // otherwise
    BookItem bi("the art of war", 20);
    MovieItem mi("interstellar", 25);

    display(fi);
    display(bi);
    // display(Item{"hello", 1}); // incorrect, missing display(Item&) function
    // display(mi); // incorrect, missing display(MovieItem&) function
}

std::vector — Four Mechanisms Behind Every push_back()

by Gracjan Olbinski

From the article:

"You call push_back() a thousand times. The vector reallocates about ten. Behind that simple interface, four mechanisms are working together — each one invisible during normal use, each one shaping your performance in ways that push_back() will never tell you about."

In this article, we'll perform some early compilation time benchmarks of one of the most awaited C++26 features.

The hidden compile-time cost of C++26 reflection

by Vittorio Romeo

From the article:

Fast compilation times are extremely valuable to keep iteration times low, productivity and motivation high, and to quickly see the impact of your changes.

I would love to see a world where C++26 reflection is as close as possible to a lightweight language feature [...]

So, I decided to take some early measurements.

Stop Choosing: Get C++ Performance in Python Algos with C++26

by Richard Hickling

From the article:

The “religious war” between Python and C++ in algorithmic trading usually boils down to a single trade-off: Python is faster for getting ideas to market, while C++ is faster for getting orders into the book.

But why choose? With the advent of C++26 Reflection, you can now have the flexibility of a Python-based strategy without the performance penalty of slow loops.

Bring in C++ Rapidly: How Reflection Works

The biggest hurdle in hybrid trading systems has always been the “bridge.” Traditionally, if you wrote a complex pricer in C++, you had to manually write “boilerplate” code to tell Python how to talk to it. If you added a new function, you had to update the bridge. It was tedious and error-prone.

Reflection changes the game by allowing the code to “look in the mirror”. Instead of you manually describing your C++ functions to Python, the compiler does it for you. It programmatically inspects your classes and generates the bindings automatically.