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.

C++26: std::is_within_lifetime

by Sandor Dargo

From the article:

When I was looking for the next topic for my posts, my eyes stopped on std::is_within_lifetime. Dealing with lifetime issues is a quite common source of bugs, after all. Then I clicked on the link and I read Checking if a union alternative is active. I scratched my head. Is the link correct?

It is — and it totally makes sense.

Let’s get into the details and first check what P2641R4 is about.

What does std::is_within_lifetime do?

C++26 adds bool std::is_within_lifetime(const T* p) to the <type_traits> header. This function checks whether p points to an object that is currently within its lifetime during constant evaluation.

The cost of a function call

by Daniel Lemire

From the article:

When programming, we chain functions together. Function A calls function B. And so forth.

You do not have to program this way, you could write an entire program using a single function. It would be a fun exercise to write a non-trivial program using a single function… as long as you delegate the code writing to AI because human beings quickly struggle with long functions.

A key compiler optimization is ‘inlining’: the compiler takes your function definition and it tries to substitute it at the call location. It is conceptually quite simple. Consider the following example where the function add3 calls the function add.

int add(int x, int y) { 
     return x + y; 
} 
int add3(int x, int y, int z) { 
     return add(add(x, y), z); 
} 

You can manually inline the call as follows.

int add3(int x, int y, int z) { 
     return x + y + z; 
}

Implementing vector<T>

by Quasar Chunawala

From the article:

The most fundamental STL data-structure is the vector. In this article, I am going to explore writing a custom implementation of the vector data-structure. The standard library implementation std::vector is a work of art, it is extremely efficient at managing memory and has been tested ad nauseam. It is much better, in fact, than a homegrown alternative would be.

Why then write our own custom vector?

• Writing a naive implementation is challenging and rewarding. It is a lot of fun!
• Coding up these training implementations, thinking about corner cases, getting your code reviewed, revisiting your design is very effective at understanding the inner workings of STL data-structures and writing good C++ code.
• Its a good opportunity to learn about low-level memory management algorithms.

We are not aiming for an exhaustive representation or implementation, but we will write test cases for all basic functionalities expected out of a vector-like data-structure.

Informally, a std::vector<T> represents a dynamically allocated array that can grow as needed. As with any array, a std::vector<T> is a sequence of elements of type T arranged contiguously in memory. We will put our homegrown version of vector<T> under the dev namespace.

Flavours of Reflection: Comparing C++26 reflection with similar capabilities in other programming languages

by Bernard Teo

From the article:

Reflection is imminent. It is set to be part of C++26, and it is perhaps the most anticipated feature accepted into this version of the standard. Lots of implementation work has already been done for Clang and GCC — they pretty much already work (both are on Compiler Explorer), and it hopefully won’t be too long before they get merged into their respective compilers.

Many programming languages already provide some reflection capabilities, so some people may think that C++ is simply playing catch-up. However, C++’s reflection feature does differ in important ways. This blog post explores the existing reflection capabilities of Python, Java, C#, and Rust, comparing them with one another as well as with the flavour of reflection slated for C++26.

In the rest of this blog post, the knowledge of C++ fundamentals is assumed (but not for the other programming languages, where non-commonsensical code will be explained).

 

IIFE for Complex Initialization

by Bartlomiej Filipek

In this article:

I hope you’re initializing most variables as const (so that the code is more explicit, and also compiler can reason better about the code and optimize).

For example, it’s easy to write:

const int myParam = inputParam * 10 + 5; 

or even:

const int myParam = bCondition ? inputParam*2 : inputParam + 10; 

But what about complex expressions? When we have to use several lines of code, or when the ? operator is not sufficient.

‘It’s easy’ you say: you can wrap that initialization into a separate function.

While that’s the right answer in most cases, I’ve noticed that in reality a lot of people write code in the current scope. That forces you to stop using const and code is a bit uglier.

So how do you quickly concatenate strings?

By Aleksandr Orefkov

From the article:

All practicing programmers have to concatenate strings. Precisely concatenate, we don’t have some JavaScript or PHP, in C++ we have this fancy word for it. Programmers in other languages ​​simply “add” strings together without much thought, without even thinking about this operation. After all, what could be simpler than

return "The answer is " + str_answer + ", count is " + count;

But while it’s forgivable for script kiddies not to think about the meaning behind such a simple notation, it’s unacceptable for an experienced developer to approach such an important issue so irresponsibly. An experienced developer, imagining such C++ code, immediately sees the terrifying abyss of problems that such an approach can create.

What type is str_answer? What type is count? “The answer is “ and “, count is “ - are literals that add to std::string as a const char*. So, strlen will be called. I wonder if the compiler will be able to optimize and calculate their length at compile time? Oh well, it seems like constexpr is in the addition, let’s hope so.
This is the first level of problems for now. And let’s say we successfully solved them, creating the following code:

std::string make_answer(std::string_view str_answer, int count) {
    return "The answer is " + std::string{str_answer}
        + ", count is " + std::to_string(count);
}

It sounds like “Hurray!”, but it’s somehow not loud enough…

15 Different Ways to Filter Containers in Modern C++

by Bartłomiej Filipek

From the article:

Do you know how many ways we can implement a filter function in C++? While the problem is relatively easy to understand – take a container, copy elements that match a predicate and the return a new container – it’s good to exercise with the C++ Standard Library and check a few ideas. We can also apply some modern C++ techniques, including C++23. Let’s start!

The problem statement

To be precise by a filter, I mean a function with the following interface:

  auto Filter(const Container& cont,
              UnaryPredicate p) {}

It takes a container and a predicate, and then it creates an output container with elements that satisfy the predicate. We can use it like the following:

  const std::vector<std::string> vec{
    "Hello", "**txt", "World", "error", "warning",
    "C++", "****" };
  auto filtered = Filter(vec, [](auto& elem) {
    return !elem.starts_with('*'); });
    // filtered should have "Hello", "World",
    // "error", "warning", "C++"

Writing such a function can be a good exercise with various options and algorithms in the Standard Library. What’s more, our function hides internal things like iterators, so it’s more like a range-based version.

Coroutines – A Deep Dive

by Quasar Chunawala

From the article:

Following on from the introduction in the editorial, let’s understand the basic mechanics needed to code up a simple coroutine, and I’ll show you how to yield from the coroutine and await results.

The simplest coroutine

The following code is the simplest implementation of a coroutine:

  #include <coroutine>
  void coro_func(){
    co_return;
  }
  int main(){
    coro_func();
  }

Our first coroutine will just return nothing. It will not do anything else. Sadly, the preceding code is too simple for a functional coroutine and it will not compile. When compiling with gcc 15.2, we get the error shown in Figure 1.

<source>: In function 'void coro_func()': <source>:4:5: error: unable to find the promise type for this coroutine 4 | co_return; | ^~~~~~~~~

Looking at C++ reference, we see that the return type of a coroutine must define a type named promise_type. Why do we need a promise? The promise_type is the second important piece in the coroutine mechanism. We can draw an analogy from futures and promises which are essential blocks for achieving asynchronous programming in C++. The future is the thing, that the function that does the asynchronous computation, hands out back to the caller, that the caller can use to retrieve the result by invoking the get() member function. The future has the role of the return object. 

Concurrency Flavours

by Lucian Radu Teodorescu

From the article:

Most engineers today use concurrency – often without a clear understanding of what it is, why it’s needed, or which flavour they’re dealing with. The vocabulary around concurrency is rich but muddled. Terms like parallelism, multithreading, asynchrony, reactive programming, and structured concurrency are regularly conflated – even in technical discussions.

This confusion isn’t just semantic – it leads to real-world consequences. If the goal behind using concurrency is unclear, the result is often poor concurrency – brittle code, wasted resources, or systems that are needlessly hard to reason about. Choosing the right concurrency strategy requires more than knowing a framework or following a pattern – it requires understanding what kind of complexity you’re introducing, and why.

To help clarify this complexity, the article aims to map out some of the main flavours of concurrency. Rather than defining terms rigidly, we’ll explore the motivations behind them – and the distinct mindsets they evoke. While this article includes a few C++ code examples (using features to be added in C++26), its focus is conceptual – distinguishing between the flavours of concurrency. Our goal is to refine the reader’s taste for concurrency.

Exclusive state access, I

by Andrzej Krzemieński

From the article:

Value semantics is a way of organizing your programs, which C++ supports and endorses. Its key characteristics in a nutshell:

1. Throughout its lifetime an object (via its type and special member functions) is used to represent a value.
2. Different parts of the program communicate values via objects. While the value matters, objects themselves (their address, their sizeof) do not.
3. Object’s value is isolated from other objects’ values.

This begs the question, what is value, but we will not answer it. First, because it is difficult, and maybe impossible. It is pretty clear what value objects of type int represent. It is fairly uncontroversial what value is represented by vector<int>, once we accept that the value representation need not fit into the sizeof of the object, but can spread across other memory locations and resources, and that vector’s capacity is not part of this value, even though it is part of its state. But there are things like std::mutex where naming the value is tricky.

Singleton done right in C++

by Andreas Fertig

From the article:

Let's use a usage pattern for a singleton that I see frequently, a system-wide logger. A simple implementation can look like the following code:

class Logger {
  Logger() = default;

public:
  static Logger& Instance()
  {
    static Logger theOneAndOnlyLogger{};

    return theOneAndOnlyLogger;
  }

  void Info(std::string_view msg) { std::print("Info: {}", msg); }
  void Error(std::string_view msg) { std::print("Error: {}", msg); }
};

The key parts for a singleton in C++ are that the constructor is private and an access function that is static. With that, you ensure that a singleton object, here Logger can only be constructed by calling Instance, essentially limiting the number of Logger objects to a single one.

You're using such a Logger like this:

Logger::Instance().Info("A test");

2025, A Year of Conferences

by Sandor Dargo

From the article:

This year I had the chance to attend three conferences onsite, plus one online, and even a meetup in my hometown, Budapest. Depending on who you ask, maybe it’s not a lot — I know some speakers do twice as many. But if you ask my family, you’d probably get a different (and understandable) answer. For me — for us — it’s a lot. It’s also an honour and a privilege in many ways.

To express my appreciation and gratitude toward the organizers and the community, I do two things:

• I try to prepare well for my talks.
• I post trip reports soon after each event — usually within a week.

Those trip reports are moderately personal: I share which talks I liked and also some of my impressions, but I try to make them useful rather than purely personal. Still, I think that once in a while, a more personal, less serious post has its place — and that’s what this one wanted to be originally.

At one of the social dinners at CppCon, a developer working for a FAANG company in New York asked me which conference I’d recommend. My answer: it depends on your goals — and your budget and constraints.

 

A Guest Editorial

by Quasar Chunawala, Frances Buontempo

From the article:

You’ve likely heard about this new C++20 feature, coroutines. I think that this is a really important subject and there are several cool use-cases for coroutines. A coroutine in the simplest terms is just a function that you can pause in the middle. At a later point the caller will decide to resume the execution of the function right where you left off. Unlike a function therefore, coroutines are always stateful - you at least need to remember where you left off in the function body.

Coroutines can simplify our code! Coroutines are a great tool, when it comes to implementing parsers.

The coroutine return type

The initial call to the coroutine function will produce a return object of a certain ReturnType and hand it back to the caller. The interface of this type is what is going to determine what the coroutine is capable of. Since coroutines are super-flexible, we can do a whole lot with this return object. If you have some coroutine, and you want to understand what it’s doing, the first thing you should look at is the ReturnType, and what it’s interface is. The important thing here is, we design this ReturnType. If you are writing a coroutine, you can decide what goes into this interface.

15 Different Ways to Filter Containers in Modern C++

by Bartłomiej Filipek

From the article:

Do you know how many ways we can implement a filter function in C++? While the problem is relatively easy to understand – take a container, copy elements that match a predicate and the return a new container – it’s good to exercise with the C++ Standard Library and check a few ideas. We can also apply some modern C++ techniques, including C++23. Let’s start!

The problem statement

To be precise by a filter, I mean a function with the following interface:

  auto Filter(const Container& cont,
              UnaryPredicate p) {}

It takes a container and a predicate, and then it creates an output container with elements that satisfy the predicate. We can use it like the following:

  const std::vector<std::string> vec{
    "Hello", "**txt", "World", "error", "warning",
    "C++", "****" };
  auto filtered = Filter(vec, [](auto& elem) {
    return !elem.starts_with('*'); });
    // filtered should have "Hello", "World",
    // "error", "warning", "C++"

Writing such a function can be a good exercise with various options and algorithms in the Standard Library. What’s more, our function hides internal things like iterators, so it’s more like a range-based version.

Time in C++: std::chrono::high_resolution_clock - Myths and Realities

by Sandor Dargo

From the article:

If there’s one clock in <chrono> that causes the most confusion, it’s std::chrono::high_resolution_clock. The name sounds too tempting — who wouldn’t want “the highest resolution”? But like many things in C++, the details matter.

In the earlier parts of this series, we looked at system_clock as the wall-clock time source, and at steady_clock as the reliable choice for measuring intervals. This time, we’ll tackle the so-called “high-resolution” clock, separate fact from myth, and see why it’s not always the right choice — even when you think you need precision.

What “high resolution” actually means

A clock’s resolution (or precision) is the granularity of its tick period — i.e., the smallest representable step in time for that clock’s time_point. In <chrono> it’s exposed via Clock::period, a std::ratio.

Notice an important difference. I didn’t mention accuracy, only precision. A clock might represent nanoseconds, but still be inaccurate due to hardware or OS scheduling. A higher resolution doesn’t necessarily mean better measurement. For timing, stability and monotonicity matter much more than how fine-grained the tick is.

Coroutines – A Deep Dive

by Quasar Chunawala

From the article:

The following code is the simplest implementation of a coroutine:

  #include <coroutine>
  void coro_func(){
    co_return;
  }
  int main(){
    coro_func();
  }

Our first coroutine will just return nothing. It will not do anything else. Sadly, the preceding code is too simple for a functional coroutine and it will not compile. When compiling with gcc 15.2, we get the error shown in Figure 1.

<source>: In function 'void coro_func()': <source>:4:5: error: unable to find the promise type for this coroutine 4 | co_return; | ^~~~~~~~~

Figure 1

Looking at C++ reference, we see that the return type of a coroutine must define a type named promise_type.

Concurrency Flavours

by Lucian Radu Teodorescu

From the article:

Most engineers today use concurrency – often without a clear understanding of what it is, why it’s needed, or which flavour they’re dealing with. The vocabulary around concurrency is rich but muddled. Terms like parallelism, multithreading, asynchrony, reactive programming, and structured concurrency are regularly conflated – even in technical discussions.

This confusion isn’t just semantic – it leads to real-world consequences. If the goal behind using concurrency is unclear, the result is often poor concurrency – brittle code, wasted resources, or systems that are needlessly hard to reason about. Choosing the right concurrency strategy requires more than knowing a framework or following a pattern – it requires understanding what kind of complexity you’re introducing, and why.

To help clarify this complexity, the article aims to map out some of the main flavours of concurrency. Rather than defining terms rigidly, we’ll explore the motivations behind them – and the distinct mindsets they evoke. While this article includes a few C++ code examples (using features to be added in C++26), its focus is conceptual – distinguishing between the flavours of concurrency. Our goal is to refine the reader’s taste for concurrency.

Finding the Next Unicode Code Point in Strings: UTF-8 vs. UTF-16

by Giovanni Dicanio

From the article:

Both UTF-16 and UTF-8 are variable-length encodings. In particular, UTF-8 encodes each valid Unicode code point using one to four 8-bit byte units. On the other hand, UTF-16 is somewhat simpler: In fact, Unicode code points are encoded in UTF-16 using just one or two 16-bit code units.

(...) The functions have the following prototypes:

// Returns the next Unicode code point and number of bytes consumed.
// Throws std::out_of_range if index is out of bounds or string ends prematurely.
// Throws std::invalid_argument on invalid UTF-8 sequence.
[[nodiscard]] std::pair<char32_t, size_t> NextCodePointUtf8(
    const std::string& str,
    size_t index
);

// Returns the next Unicode code point and the number of UTF-16 code units consumed.
// Throws std::out_of_range if index is out of bounds or string ends prematurely.
// Throws std::invalid_argument on invalid UTF-16 sequence.
[[nodiscard]] std::pair<char32_t, size_t> NextCodePointUtf16(
    const std::wstring& input,
    size_t index
);

Practical Security in Production: Hardening the C++ Standard Library at massive scale

by Louis Dionne, Alex Rebert, Max Shavrick, and Konstantin Varlamov

From the article:

Over the past few years there has been a lot of talk about memory-safety vulnerabilities, and rightly so—attackers continue to take advantage of them to achieve their objectives. Aside from security, memory unsafety can be the cause of reliability issues and is notoriously expensive to debug. Considering the billions of lines of C++ code in production today, we need to do what we can to make C++ measurably safer over the next few years with as low of an adoption barrier as possible.

In 2019, Alex Gaynor, a security expert and one of the leading voices in memory safety, wrote a piece titled "Modern C++ Won't Save Us," where he gave examples of foundational types such as std::optional that were unsafe in the idiomatic use cases. What happens when these unsafe types are used beyond their contract? Well, you guessed it: undefined behavior. The std::optional type isn't the only one to behave like this. If you look at how this compares with modern languages, you can see that C++ is the outlier.

So, what's to be done? Possibly one of the best places to start today is by improving our standard libraries. They provide the baseline "vocabulary types" for developers—and if they're not safe, it will be tough to build safety around them. The std::optional type is only one of many vocabulary types in the C++ Standard Library that aren't safe by default today. Given the current state, it seems mostly clear that the first step should be hardening our standard library, and in our case, this was LLVM's libc++.

Qt completes the recommended public cash offer to the shareholders of I.A.R. Systems Group

From the article:

On 4 July 2025, Qt Group Plc's ("Qt Group") wholly owned subsidiary The Qt Company Ltd ("The Qt Company" and together with Qt Group, "Qt"), announced a recommended public cash offer to the shareholders of class B shares (the "Shares" or, individually, a "Share") in I.A.R. Systems Group AB (publ) ("IAR"), to tender all their Shares at a price of SEK 180 in cash per Share (the "Offer"). The Shares in IAR are traded on Nasdaq Stockholm, Mid Cap. An offer document relating to the Offer was published on 15 August 2025.

At the end of the acceptance period on 10 October 2025, the Offer had been accepted by shareholders with a total of 12,037,848 Shares in IAR, corresponding to 94.49 per cent of the outstanding shares and votes in IAR.[1] As a result, The Qt Company controls in total 12,037,848 Shares in IAR, corresponding to 94.49 per cent of the outstanding shares and votes in IAR.[2]

The Qt Company has decided to complete the Offer. All conditions are satisfied or have been waived. Settlement for Shares tendered in the Offer during the initial acceptance period will be initiated on or around 17 October 2025.

 

Event-driven flows

by Andrzej Krzemieński

From the article:

A canonical example of an event-driven flow is the handling of signals in C. Signals will be risen at unpredictable points in time, so rather than actively checking for them, we define a callback and associate it with the indicated signal:

signal(SIGINT, on_interrupt);

 

After having performed this association, we move on to doing other things. It is the implementation (system, or parts of the program we do not write) that will make sure to invoke the callback when the signal is risen (if at all). We can illustrate it with a diagram:

Converting Between Unicode UTF-16 and UTF-8 in Windows C++ Code

by Giovanni Dicanio

From the article:

A detailed discussion on how to convert C++ strings between Unicode UTF-16 and UTF-8 in C++ code using Windows APIs like WideCharToMultiByte, and STL strings and string views.

 

C++ Standard Evolution Viewer

by Jason Turner

From the article:

This site provides an interactive way to explore changes in the C++ standard by viewing side-by-side diffs of individual sections (identified by stable names like [array], [class.copy], [ranges.adaptors]).

Each version transition below focuses on Tier 1 sections (major library components and language features) to provide the most educational value.

Structured iteration

by Andrzej Krzemieński

From the article:

These problems do not occur when you use the range-based for-loop.

This C++11 addition, apart from other conveniences, is a safety feature (as in language-safety): it is very hard to use it incorrectly. It is not flexible, or versatile. You have to pass it a range, you have to give a name to an element referenced in each iteration step. There is no "control variable" (like i), so you cannot get the operations on it wrong. A number of bugs are prevented simply by employing a range-based loop.

But what if my iteration is more complicated? What if I need to visit my elements in reverse?

 

Trip report: Meeting C++ 2025

by Sandor Dargo

From the article:

I remember that last year I said that Berlin in November is the perfect place to have a conference because you want to be inside that four-star hotel and not outside. This year, the conference was held a week earlier, and the weather was so nice that it was actually tempting to go out and explore.

But people resisted the temptation. The lineup and content were very strong — this year there were more than 50 talks across 5 different tracks. Also, Meeting C++ is a fully hybrid conference, so you can join any talk online as well.

It might sound funny, but I must mention that the food is just great at Meeting C++. It’s probably the conference with the best catering I’ve ever been to — from lunch to coffee breaks, everything was top-notch.

This year, there were no evening programs. I’m not complaining; it’s both a pity and a blessing, and I’m not sure how I feel about it. For example, when I first attended C++ On Sea, there were no evening events, and I really enjoyed discovering Folkestone in the evenings. Over the years, the schedule there got extended, and sometimes I had no time to visit my favorite places. But at least some socializing was guaranteed. One can say that you can do it on your own, but many of us are introverted, and if we’re not forced to socialize, we just won’t. That’s even easier to avoid in a big city like Berlin. I remember that last year I didn’t have time to go out until the end of the conference. It was different this year.

But let’s talk about the talks.

My three favourite talks

Let me share with you the three talks I liked the most. They are listed in chronological order...

C++ Enum Class and Error Codes

by Mathieu Ropert

From the article:

Most of my readers, I hope, have been able to use C++11 for a while now (if not hello, I’m sorry the world has changed to become this weird during your 14 years sleep). With it came a small change that allowed for better scoping of names without resorting to weird quirks: enum class. The idea is simple: owing to C, enum values in C++ belong to the class or namespace they are declared in but if we add the class keyword to the declaration they know become their own scope instead of leaking to their parent.

This was a simple quality of life change in the compiler to address a weakness in the language that folks usually worked around by either adding long prefix to the enum values (C style) or wrapping them within structs or classes (C++98/03 style). And with it came the incentive to migrate C era error code enums to scoped enums. But there’s a catch.

Trip report: Budapest C++ - Breaking & Building C++

by Sandor Dargo

From the article:

More than a hundred people registered, and the room quickly filled up with local developers eager to hear three technical talks. The atmosphere was lively and welcoming — it showed the strength of the C++ community in Budapest. In 2027, even WG21 might come to Hungary!

The evening began with Jonathan Müller’s talk, Cache-Friendly C++, followed by my own session on Strongly Typed Containers. Finally, Marcell Juhász closed the event with an insightful and hands-on presentation on Hacking and Securing C++.

Speeding up C++ functions with a thread_local cache

by Daniel Lemire

From the article:

In large code bases, we are often stuck with unpleasant designs that are harming our performance. We might be looking for a non-intrusive method to improve the performance. For example, you may not want to change the function signatures.

Let us consider a concrete example. Maybe someone designed the programming interface so that you have to access the values from a map using an index. 

 

Using RAII to remedy a defect where not all code paths performed required exit actions

by Raymond Chen

From the article:

A team asked me to review their pull request that fixed a bug that was caused by failing to perform some required action along all code paths. Here’s a simplified sketch:

void MySpecialFeature::OnButtonClick()
{
    try {
        auto file = PickFile();
        if (!file) {
            DismissUI();
            return;
        }

        if (ConfirmAction()) {
            if (m_useAlgorithm1) {
                // StartAlgorithm1 invokes the lambda when finished.
                StartAlgorithm1(file, [self = shared_from_this()] {
                    self->DismissUI();
                });
            } else {
                RunAlgorithm2(file);
                DismissUI();
            }
        } else { // this block was missing
           DismissUI(); 
        } 
    } catch (...) {
        DismissUI();
    }
}

Open wide: Inspecting LLVM 21 with static analysis

by Nikita Terentev

From the article:

As we can see, error logging will never be executed, and, moreover, execution will always continue with potentially incorrect behavior. Here's what git blame reports: the code celebrates its tenth anniversary in November. One might think its meaning had changed over time. But no, history confirms that Defs has always been DenseMap, and its count function only returned 0 or 1 back then. If we search for other similar checks, we see that the count result is used as a binary value everywhere.

C++ Templates: How to Iterate through std::tuple: C++26 Packs and Expansion Statements

by Bartlomiej Filipek

From the article:

In part 1 of this mini-series, we looked at the basics of iterating over a std::tuple using index_sequence and fold expressions. In part 2, we simplified things with std::apply and even created helpers like for_each_tuple and transform_tuple.

So far, we used C++ features up to C++20/23… but now, in C++26, we finally get language-level tools that make tuple iteration straightforward and expressive. In this article, we’ll explore two new techniques:

• Structured bindings can introduce a pack - P1061 - turn a tuple into a pack of variables.
• Expansion statements P1306 - the ultimate “compile-time loop” syntax.

Bjarne Stroustrup: Concept-Based Generic Programming

https://www.stroustrup.com/Concept-based-GP.pdf

We present programming techniques to illustrate the facilities and principles of C++ generic programming using concepts. Concepts are C++’s way to express constraints on generic code. As an initial example, we provide a simple type system that eliminates narrowing conversions and provides range checking without unnecessary notational or run-time overhead.

User-Defined Formatting in std::format

by Spencer Collyer

From the article:

In a previous article [Collyer21], I gave an introduction to the std::format library, which brings modern text formatting capabilities to C++.

That article concentrated on the output functions in the library and how they could be used to write the fundamental types and the various string types that the standard provides.

Being a modern C++ library, std::format also makes it relatively easy to output user-defined types, and this series of articles will show you how to write the code that does this.

There are three articles in this series. This article describes the basics of setting up the formatting for a simple user-defined class. The second article will describe how this can be extended to classes that hold objects whose type is specified by the user of your class, such as containers. The third article will show you how to create format wrappers, special purpose classes that allow you to apply specific formatting to objects of existing classes.

A note on the code listings: The code listings in this article have lines labelled with comments like // 1. Where these lines are referred to in the text of this article, it will be as ‘line 1’ for instance, rather than ‘the line labelled // 1’.

std::ranges may not deliver the performance that you expect

by Daniel Lemire

From the article:

Good engineers seek software code that is ‘simple’ in the sense that we can read and understand it quickly. But they they also look for highly performant code.

For the last 20 years, we have been offering programmers the possibility to replace conventional for loops with a more functional approach. To illustrate, suppose that you want to extract all even integers from a container and create a new container. In conventional C++, you would proceed with a loop, as follows.

std::vector<int> even_numbers;
for (int n : numbers) {
 if (n % 2 == 0) {
 even_numbers.push_back(n);
 }
}

C++26: std::optional<T&>

by Sandor Dargo

From the article:

At CppCon I attended a great talk by Steve Downey about std::optional<T&>. Steve is the father of optional references—he co-authored P2988R12 with Peter Sommerlad.

Let’s start with a little history. By now — at the end of 2025 — even C++17 feels like history. That’s when std::optional<T> was introduced, giving us a way to represent “maybe a value” with value semantics, instead of relying on pointers. But std::optional in C++17 (and later) couldn’t hold references — unless you wrapped them in std::reference_wrapper.

C++26 finally fixes this gap.

What is std::optional<T&>?

std::optional<T&> has three key characteristics:

• Unlike std::optional<T>, it is not an owning type. It simply refers to an existing object.
• It provides both reference and value-like semantics.
• Internally, it behaves like a pointer to T, which may also be nullptr.

This last point is interesting: while optional<T> can be seen as variant<T, monostate>, optional<T&> is closer to variant<T&, nullptr_t>. In practice, it’s a safer alternative to a non-owning raw pointer.

The problem with inferring from a function call operator is that there may be more than one

by Raymond Chen

From the article:

Some time ago, I wrote briefly on writing a helper class for generating a particular category of C callback wrappers around C++ methods. This particular mechanism used a proxy object with a templated conversion operator to figure out what function pointer type it was being asked to produce.¹

But what about taking a std::invoke‘able object and inferring the function pointer from the parameters that the invoke‘able’s operator() accepts?

Sure, you could try to do that, but there’s a catch: There might be more than one operator().

The common case of this is a lambda with auto parameters.

RegisterCallback(
    CallableWrapper([](auto first, auto second, auto third) {
        ⟦ ... ⟧
    }, context);

A Month of Writing Reflections-based Code: What have I learned?

by Boris Staletić

From the article:

I have been trying to automate writing my own pybind11 binding code with the help of C++26 reflections, as implemented by clang-p2996.

There were moments where things went smoothly, but also moments where I missed a feature or two from the world of reflections. Then there is also accidental complexity caused by pybind11 having features which are, at the very least, not friendly for generic binding generation.

Before I begin, a massive thanks to Barry Revzin, Daveed Vandevoorde, Dan Katz, Adam Lach and whoever else worked on bringing Reflections to C++.

Smooth sailing

What we got from the set of reflections papers is awesome. Here's an example of what can be achieved quite easily:

https://godbolt.org/z/jaxT8Ebjf

With some 20 lines of reflections, we can generate bindings that cover:

• free functions (though not overload sets of free functions - more on that later)

• structs/classes with

  • a default constructor

  • member functions

  • data members, though always writable from python

You can also see how this easily generalizes to all other kinds of py_class.def_meow(...). Almost... Since C++ does not have "properties" in the python sense, def_property_meow will need special care.

This week, let’s move further — shifting away from inheritance and embracing composition.

Discovering Observers - Part 3

by Sandor Dargo

From the article:

You might say (and you’d be right) that publishers and subscribers can just as well be used as members instead of base classes. In fact, with our previous implementation, handling changes inside subscribers felt more complicated than necessary.

What we’d really like is this: subscribers that observe changes and trigger updates in their enclosing class in a coherent way. As one of the readers of Part 1 pointed out, this can be elegantly achieved if subscribers take callables.

Step 1: Subscribers with callables

We start by letting Subscriber accept a std::function, which gets called whenever the subscriber is updated:

Why can’t std::apply figure out which overload I intend to use? Only one of them will work!

by Raymond Chen

From the article:

Consider the following:

void f(int, int);
void f(char*, char*);

void test(std::tuple<int, int> t)
{
    std::apply(f, t); // error
}

The compiler complains that it cannot deduce the type of the first parameter.

I’m using std::apply here, but the same arguments apply to functions like std::invoke and std::bind.

From inspection, we can see that the only overload that makes sense is f(int, int) since that is the only one that accepts two integer parameters.

But the compiler doesn’t know that std::apply is going to try to invoke its first parameter with arguments provided by the second parameter. The compiler has to choose an overload based on the information it is given in the function call.

Discovering Observers - Part 2

by Sandor Dargo

From the article:

Last week, we took the observer pattern from a very simple example and evolved it into a more flexible, template-based implementation in C++. We ended up with abstracted publishers and subscribers, a templated message type for flexibility, and publishers controlling when and how updates are pushed.

This week, we’re going to tackle the challenge of supporting multiple message types in a single publisher.

First attempt: multiple inheritance of templated bases

It’s tempting to provide different specializations for our templates so the same publisher can push different message types.

The last update to the schedule for Meeting C++ 2025

by Jens Weller

From the article:

With release of the static html schedule for the website everything is ready for Meeting C++ 2025!

For a few years now Meeting C++ offers two schedules: the live schedule is coming from the database, which allows us to make changes during the conference. The other schedule is part of the static website and just a single page powered by the C++ CMS from Meeting C++. Due to the 5th track this year I've just had one week before the conference the time to update the website with this now final program for the conference.

 

Looking at binary trees in C++

by Jens Weller

From the article:

I'm in the process of preparing a quick talk on trees in C++ for Meeting C++ 2025. In order to see what the web offers, I've searched exactly for this, "trees in C++".

This showed that most posts found by duckduckgo or google were about binary trees, and in particular the same or similar implementation of using raw pointers for the left/right elements in the tree. Including using new to allocate for the nodes, only some times the code also bothers with using delete. The basic node class looks like this: