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.

 

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:

 

Introducing the Constexpr Debugger -- Alexander Karaev

By Blog Staff | Oct 23, 2025 01:02 PM | Tags: None

The new Constexpr Debugger available in the first CLion 2025.3 EAP build allows you to stay in the compiler’s world and see what really happens – by stepping through evaluation, inspecting values, and confirming which if constexpr branch fired. Using it helps you understand exactly what the compiler is doing and fix issues faster.

Introducing the Constexpr Debugger

by Alexander Karaev

From the article:

“Not a constant expression.” You’ve seen the diagnostics and the note trail, but never the actual state. Until now.

Modern C++ pushes more logic into constexpr/consteval: parsers, tables, DSLs, hashing – real code with real branches. When code fails at compile time, you can either try to guess the reason from the compiler’s notes or de‑constexpr it and hope the runtime reproduction matches what the compiler actually did.

The new Constexpr Debugger available in the first CLion 2025.3 EAP build allows you to stay in the compiler’s world and see what really happens – by stepping through evaluation, inspecting values, and confirming which if constexpr branch fired. Using it helps you understand exactly what the compiler is doing and fix issues faster.

Discovering Observers - Part 1 -- Sandor Dargo

By Blog Staff | Oct 18, 2025 01:14 PM | Tags: None

The goal of this mini-series is to explore the Observer Design Pattern in C++, walking through different implementations and weighing their pros and cons.

Discovering Observers - Part 1

by Sandor Dargo

From the article:

First, let’s briefly recap what the observer pattern is. It belongs to the family of behavioral design patterns.

As a reminder: design patterns are usually grouped into three categories: creational, structural, and behavioral.

You might also have encountered the observer under other names such as listener, event subscriber, or publisher-subscriber.

The central idea is simple: instead of repeatedly querying an object for information, the querying object (the observer) gets notified automatically when the information holder (the subject) changes. For example, imagine an orchestrator object that needs the latest value of a user setting. Instead of polling the setting every n milliseconds, it can subscribe to value changes and receive notifications whenever a new value is set.

Using the common terminology: there is typically one publisher and one or more subscribers. Subscribers register for events or changes, and whenever an update happens, the publisher notifies them.

Trip Report: CppCon 2025 -- Sandor Dargo

By Blog Staff | Oct 14, 2025 01:10 PM | Tags: None

A long-delayed dream finally came true: after years of near-misses and lessons learned (“better to be invited than sent”), I made it to CppCon—and it was bigger, louder, and more inspiring than I imagined. In this recap I share the vibe of the week, five standout talks and ideas, a few notes from my own session, and links to recordings as they appear.

Trip Report: CppCon 2025

by Sandor Dargo

From the article:

CppCon is simply bigger than any other C++ conference I’ve attended. A massive venue packed with people and sponsors. I logged more than 10,000 steps on the very first day — without ever leaving the resort or going to the gym.

The whole experience felt like it was on another scale compared to European conferences (which I also love). But then again, that’s often the impression when you see something American from a European perspective, isn’t it?

I never would have imagined a C++ conference where a live band plays while Bjarne Stroustrup himself makes final checks before stepping on stage to deliver the opening keynote. Absolutely rocks.

Structured Bindings in C++17, 8 Years Later -- Bartlomiej Filipek

By Blog Staff | Oct 9, 2025 12:42 PM | Tags: None

Structured binding is a C++17 feature that allows you to bind multiple variables to the elements of a structured object, such as a tuple or struct. This can make your code more concise and easier to read, especially when working with complex data structures. On this blog, we already covered this functionality, but we’ll talk about some good C++26 additions and real code use cases.

Structured bindings in C++17, 8 years later

by Bartlomiej Filipek

From the article:

An excellent demonstration of structured bindings is an iteration through a map object.

If you have a std::map of elements, you might know that internally, they are stored as pairs of <const Key, ValueType>.

Now, when you iterate through elements, you can do:

for (const auto& elem : myMap) { ... } 

You need to write elem.first and elem.second to refer to the key and the value.

std::map<KeyType, ValueType> myMap = getMap(); 
// C++14: 
for (const auto& elem : myMap) {  
     // elem.first - is the key  
     // elem.second - is the value 
}