AddressSanitizer continue_on_error

by Jim Radigan

Monitor Object

by Rainer Grimm

Problem

If many threads access a shared object concurrently, the following challenges exist.

• Due to the concurrent access, the shared object must be protected from non-synchronized read and write operations to avoid data races.
• The necessary synchronization should be part of the implementation, not the interface.
• When a thread is done with the shared object, a notification should be triggered so the next thread can use the shared object. This mechanism helps avoid and improves the system's overall performance.
• After the execution of a member function, the invariants of the shared object must hold.

Solution

A client (thread) can access the Monitor Object's synchronized member functions, and due to the monitor lock, only one synchronized member function can run at any given time. Each Monitor Object has a monitor condition that notifies the waiting clients.

Finite State Machine with std::variant

by Bartlomiej Filipek

Let’s start with a basic example:

• we want to track a game player’s health status
• we’d like to respond to events like “Hit by a monster” or “Healing bonus.”
• when the health point goes to 0, then we have to restart the game only if there are some remaining lives available

Here’s a basic diagram with states and transitions:

New C++ features in GCC 13

by Marek Polacek

Like the article I wrote about GCC 10 and GCC 12, this article describes only new features implemented in the C++ front end; it does not discuss developments in the C++ language itself. Interesting changes in the standard C++ library that comes with GCC 13 are described in a separate blog post: New C features in GCC 13

Active Object

by Rainer Grimm

The Active Object decouples method invocation from method execution. The method invocation is performed on the client thread, but the method execution is on the Active Object. The Active Object has its thread and a list of method request objects (short request) to be executed. The client’s method invocation enqueues the requests on the Active Object’s list. The requests are dispatched to the servant.

When many threads access a shared object synchronized, the following challenges must be solved:

• A thread invoking a processing-intensive member function should not block the other threads invoking the same object for too long.
• It should be easy to synchronize access to a shared object.
• The concurrency characteristics of the executed requests should be adaptable to the concrete hardware and software.

Solving Undefined Behavior in Factories with constinit from C++20

by Bartlomiej Filipek

Let’s bring back the topic:

Here’s a typical factory function. It creates unique_ptr with ZipCompression or BZCompression based on the passed name/filename:

Here are some issues with this approach:

• Each time you write a new class, and you want to include it in the factory, you have to add another if in the Create() method. Easy to forget in a complex system.
• All the types must be known to the factory.
• In Create(), we arbitrarily used strings to represent types. Such representation is only visible in that single method. What if you’d like to use it somewhere else? Strings might be easily misspelled, especially if you have several places where they are compared.

All in all, we get a strong dependency between the factory and the classes.

But what if classes could register themselves? Would that help?

The Move Constructor That You Have to Declare, Even Though You Don’t Want Anyone to Actually Call It

by Raymond Chen

Blah blah blah C++ return value optimization (RVO), named return value optimization (NRVO), and copy elision.

RVO support was optional in C++11 but became mandatory in C++17. NRVO support remains optional (but recommended).

To allow NRVO in C++17 (or RVO and NRVO in C++11), a move constructor must be available, even though the compiler will not call it if the optimization is employed.

You may have a class that you want to participate in RVO or NRVO, but you also don’t want it to be moved. For example, it may contain a std::mutex, which is not movable. But you nevertheless have to declare a move constructor. What can you do?

Declare the move constructor, but...

Need Something Sorted? Sleep On It!

by Kevlin Henney

A decade ago, I first presented a lightning talk entitled ‘Cool Code’. This short talk evolved into a full talk whose iterations I presented over the next half decade. The focus? Code that, for some reason or other, can be considered cool. For example, code that has played a significant role in historical events, such as the source for the Apollo Guidance Computer [Apollo]. Or code that is audacious – if not seemingly impossible – given its constraints, such as David Horne’s 1K chess [Frogley01]. There is code that is both simple and profound, such as Peter Norvig’s fits-on-a-slide spelling corrector [Norvig16]. And code that demonstrates ingenuity and humour, such as Yusuke Endoh’s Qlobe [Endoh10].

Leaving aside its content for a moment, one of the most interesting things about the talk was its...

Modern C++ In-Depth — Transparent Comparisons

by Michael Kristofik

Searching for an element in a container normally requires constructing an object of the container’s key_type. If the key is small, such as one you’d normally pass by value, it isn’t a performance concern. But what if the key is large?

Why You Should Only Rarely Use std::move

by Andreas Fertig

The example in Listing 1 is the code I used to make my point: don’t use std::move on temporaries! Plus, in general, trust the compiler and only use std::move rarely. For this article, let’s focus on the example code.

class S {
public:
  S() { printf("default constructor\n"); }
  ~S() { printf("deconstructor\n"); }
  // Copy constructor ①
  S(const S&) { printf("copy constructor\n"); }
  // Move constructor ②
  S(S&&) { printf("move constructor\n"); }
};
void Use()
{
  S obj{
    S{} // Creating obj with a temporary of S ③
  };
}

Here we see a, well, perfectly movable class. I left the assignment operations out. They are not relevant. Aside from the constructor and destructor, we see in ① the copy constructor and in ② the move constructor. All special members print a message to identify them when they are called.