Home »

Concept-Based Generic Programming -- Bjarne Stroustrup

By Bjarne Stroustrup | Nov 22, 2025 02:14 PM | Tags: None

A new paper:

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 -- Spencer Collyer

By Blog Staff | Nov 21, 2025 02:51 PM | Tags: None

logo.pngstd::format allows us to format values quickly and safely. Spencer Collyer demonstrates how to provide formatting for a simple user-defined class.

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 -- Daniel Lemire

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

Capture-decran-le-2025-10-05-a-17.34.45-825x510.pngModern 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

SANDOR_DARGO_ROUND.JPGIf 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

RaymondChen_5in-150x150.jpgIn 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

Depositphotos_193487310_L.jpgThis 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

SANDOR_DARGO_ROUND.JPGOver 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

RaymondChen_5in-150x150.jpgWhen 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.