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 
}

You should use QPainterPath they said...

By Meeting C++ | Oct 8, 2025 10:21 AM | Tags: qt meetingcpp community

A blog entry about this years t-shirt at Meeting C++ 2025 and exploring QPainterPath for it.

You should use QPainterPath they said...

by Jens Weller

From the article:

This post is about what I learned while playing around with QPainterPath for this years t-shirt at Meeting C++ 2025 sponsored by Hudson River Trading.

One of the issues from last years t-shirt was when using drawText from QPainter, one does not really *draw* text in an svg exported. Instead you'll get the text and the font kinda embedded in an svg. What good is that in a vector graphic? This was a bit of a surprise when I ran into issues with this last year during printing. While this could be solved with the printing company picking a different font, it would have been also solved by using QPainterPath. At least this was the feedback from some of the Qt experts present onsite or online...