SObjectizer Tales – 28. If I had a magic wand...

by Marco Arena

In this episode I delve into what I dislike the most about the library and explore what I would change if I had a magic wand.

SObjectizer Tales – 27. Design ideas

by Marco Arena

In this episode we aim to inspire new ideas and approaches to design applications using SObjectizer and its paradigm.

Trip Report: Spring ISO C++ Meeting in Tokyo, Japan

by Jonathan Müller

I started the week on Monday in LEWG, the working group for the C++ standard library design. After the usual papers adding/extending std::format (Victor Zverovich keeps us busy), we approved a proposal that adds thread attributes, and reviewed the library parts of P2900 contracts. LEWG being LEWG, we mostly complained about the names (std::contracts::contract_violation has too many contracts in it), but overall liked it. However, contracts are a language feature, and the real controversy was over at EWG, the language design group. In particular, what happens if you have undefined behavior in a precondition? Consider the following example:

std::string_view slice(std::string_view str, int pos, int length)
pre (0 <= pos && pos <= std::ssize(str) && 0 <= length && pos + length <= std::ssize(str))
{
return std::string_view(str.data() + pos, str.data() + pos + length);
}

A slicing function for std::string_view using signed integers for demonstration purposes.

An integer overflow of pos + length in the precondition is undefined behavior. Some argue that this should instead be well-defined and lead to a precondition violation. While this would be nice and can lead to a general "safe mode" of C++ which could (and should!) be usable outside of contracts as well, I don't see how it can be worked out before C++26. I'd much rather have contracts with undefined behavior in C++26 then delaying it even further. The nice thing about undefined behavior is that it can be always well-specified later.

How not to check array size in C++

by Mikhail Gelvikh

Since we're coding in C++ here, let's harness the power of templates! This brings us to the legendary ArraySizeHelper (aka "the safe sizeof" in some articles), which developers write sooner or later in almost every project. In the old days — before C++11 — you could encounter such monstrosities.

SObjectizer Tales – 26. Dispatcher selection

by Marco Arena

In this episode we explore guidelines and considerations for binding agents to dispatchers. We'll emphasize the significance of asking pertinent questions rather than expecting definitive answers, as the decision-making process hinges on the unique requirements of the system.

SObjectizer Tales – 25. Runtime telemetry

by Marco Arena

In this episode we learn how to get insights into application performance using SObjectizer's monitoring system.

C++ and The Next 30 Years

by David Sankel

My talk: C++ and the Next 30 Years

The title of my keynote was C++ and the Next 30 Years which covered C++’s evolution, the changing landscape of programming languages, and the influence of AI. Here I break down some of my talk’s key points.

The next 10 years

In the next 10 years I expect C++ modules to become more accessible. Most C++ vendors have at least some support and CMake recently announced its feature set. However, transitioning existing code bases and, in many instances, bespoke build systems will be a great obstacle.

Package manager usage is on the rise, but the growth curve is slow. I don’t expect any tool to capture more than 40% market share by the decade’s end.

Is shadowing a member variable from a base class a bad thing? Maybe, but maybe not.

by Raymond Chen

What is shadowing? In C++, shadowing is the name given to the phenomenon when a name in one scope hides an identical name in another scope.

Is shadowing bad? That’s a harder question.

Whether shadowing is good or bad depends on the order in which the conflicting names were introduced.

Suppose you have a class library, and one of the classes is this:

struct Tool {
    int a;
};

And suppose some customer uses your class like this:

class Wrench : public Tool {
private:
    int a;
};

In this case, shadowing is probably unintended. The customer has accidentally shadowed Tool::a, and any references to a in the Wrench class will refer to Wrench::a, even if the author meant to access Tool::a.

Meanwhile, you have another customer who writes this...

SObjectizer Tales – 24. Delivering messages at shutdown

by Marco Arena

In this episode we learn a feature of SObjectizer to perform arbitrary actions just before shutdown, including message delivery.

Providing a stable memory address

by Jens Weller

Some APIs allow you to store a pointer to your data element. This is used to access additional information from your types to display them in Model/View Architecture.

A while ago I showed how you can implement a tree with shared_ptr and enable_shared_from_this and then display this in QTreeView. And when working on my current project I knew this problem would come around again. Maybe not for a tree and a tree view, but I'll clearly need to have some way to have ui panels display and edit my data classes and store a stable memory adress as a pointer in Qt models. Back in 2015 the Qt5 example still used a pointer allocated with raw new for this, in Qt6 the example uses unique_ptr. Using shared_ptr for this back in 2015 was a good decision, and the code works very well. For the moment I don't see that my current project would need to make use of enable_shared_from_this, so using unique_ptr would be a good option...