std::ranges may not deliver the performance that you expect -- Daniel Lemire

By Blog Staff | Nov 19, 2025 02:48 PM | Tags: None

Modern C++ offers elegant abstractions like std::ranges that promise cleaner, more expressive code without sacrificing speed. Yet, as with many abstractions, real-world performance can tell a more nuanced story—one that every engineer should verify through careful benchmarking.

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 -- Sandor Dargo

By Blog Staff | Nov 17, 2025 02:43 PM | Tags: None

If you’re a regular reader of Sandor's blog, you know he's been sharing what he learned about new C++ language and library features ever since C++20. You probably also read his CppCon 2025 Trip Report. And this post is where the two come together.

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 -- Raymond Chen

By Blog Staff | Nov 14, 2025 02:39 PM | Tags: None

In this post, we’ll take a closer look at how to extend the earlier callback wrapper mechanism to handle regular function pointers as well as member functions. Along the way, we’ll examine some of the subtleties of inferring function pointer types from callable objects—especially when lambdas with auto parameters enter the picture.

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? -- Boris Staletić

By Blog Staff | Nov 12, 2025 12:28 PM | Tags: None

This post chronicles a month-long experiment using C++26 reflections to automate the generation of pybind11 bindings, blending the promise of modern metaprogramming with real-world complexity. It offers a candid look at what worked beautifully, what fell short, and what future language features could make reflection-driven automation even more powerful.

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.

Discovering Observers - Part 3 -- Sandor Dargo

By Blog Staff | Nov 5, 2025 01:16 PM | Tags: None

Over the last two posts, we explored different implementations of the observer pattern in C++. We began with a very simple example, then evolved toward a more flexible, template- and inheritance-based design.

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? -- Raymond Chen

By Blog Staff | Oct 31, 2025 01:15 PM | Tags: None

When you pass an overloaded function like f to std::apply, the compiler can’t peek inside the tuple to figure out which overload matches—it only sees an ambiguous callable and a single tuple argument. Because overload resolution happens before the tuple is unpacked, you need an extra layer (like a lambda) to forward the unpacked arguments and give the compiler enough information to pick the correct overload.

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 -- Sandor Dargo

By Blog Staff | Oct 28, 2025 01:04 PM | Tags: None

In the last post, we built a templated observer framework that let any publisher push strongly-typed messages to its subscribers.
This time we’ll push the design further by trying to let a single publisher handle multiple message types—and we’ll quickly see how that innocent goal invites ambiguity, boilerplate, and some surprising trade-offs.

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 final schedule for Meeting C++ 2025 has been published

By Meeting C++ | Oct 28, 2025 09:42 AM | Tags: meetingcpp community

With today, the final schedule for Meeting C++ 2025 has been published. Tickets for Berlin and online are still available until next week Wednesday!

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.

 

Celebrating C++’s 40th birthday at C++ Day in Italy

By Marco Arena | Oct 27, 2025 06:42 AM | Tags: community

This year marks C++'s 40th anniversary, and at C++ Day 2025 (a proper "wrap-up post" will follow in the next days) we couldn't let the occasion pass without a little celebration!

While there wasn't a cake, we gathered everyone to sing "Happy Birthday, C++":

Followed by a lively game that mixed 1980s pop culture, ISO C++ trivia, Bell Labs history, and more:

Over 160 people joined the event, with about 120 staying until the end to play and win some unique prizes: 1980s-style posters featuring movie quotes reimagined with a C++ twist:

And we had a winner!

Also we ran a raffle including all quiz participants:

The posters also decorated the venue all day long, giving it a warm, retro, and festive feel:

It was a small but heartfelt way to celebrate four decades of a language that continues to inspire and evolve.

Here's to the next 40 years of C++!

Looking at binary trees in C++

By Meeting C++ | Oct 24, 2025 08:22 AM | Tags: meetingcpp community

While preparing a talk for Meeting C++ 2025 I've started looking into binary trees. And got curious about a different design choice.

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: