C++23: The Next C++ Standard

By Rainer Grimm

The C++ Standards

C++ is more than 40 years old. What happened in the last years? Here is a simplified answer ending in C++23.

C++98

At the end of the 80ths, Bjarne Stroustrup and Margaret A. Ellis wrote their famous book Annotated C++ Reference Manual (ARM). These books served two purposes. First, there were many independent C++ implementations. ARM defined, therefore, the functionality of C++. Second, ARM was the base for the first C++ standard: C++98 (ISO/IEC 14882). C++98 had a few essential features: templates, the standard template library (STL) with its containers and algorithms, strings, and IO streams.

C++03

With C++03 (14882:2003), C++98 got a technical correction that is so small that there is no place on my timeline. In the community, C++03, which includes C++98, is called legacy C++.

Constrain Your User-Defined Conversions

By Jonathan Mueller

Sometimes you want to add an implicit conversion to a type. This can be done by adding an implicit conversion operator. For example, std::string is implicitly convertible to std::string_view:

	class string { // template omitted for simplicity
	public:
	    operator std::string_view() const noexcept
	    {
	       return std::string_view(c_str(), size());
	    }
	}; 

The conversion is safe, cheap, and std::string and std::string_view represent the same platonic value — we match Tony van Eerd’s criteria for implicit conversions and using implicit conversions is justified.

However, even when all criteria are fulfilled, the conversion can still be dangerous.

Thread-Safe Queue - Two Serious Errors

by Rainer Grimm

First, I want to show you again the erroneous implementation from my last post to understand the context.

// monitorObject.cpp

#include <condition_variable>
#include <functional>
#include <queue>
#include <iostream>
#include <mutex>
#include <random>
#include <thread>

class Monitor {
public:
    void lock() const {
        monitMutex.lock();
    }

    void unlock() const {
        monitMutex.unlock();
    }

    void notify_one() const noexcept {
        monitCond.notify_one();
    }

    template <typename Predicate>
    void wait(Predicate pred) const {                 // (10)
        std::unique_lock<std::mutex> monitLock(monitMutex);
        monitCond.wait(monitLock, pred);
    }
  
private:
    mutable std::mutex monitMutex;
    mutable std::condition_variable monitCond;
};

template <typename T>                                  // (1)
class ThreadSafeQueue: public Monitor {
public:
    void add(T val){
        lock();
        myQueue.push(val);                             // (6)
        unlock();
        notify_one();
    }
  
    T get(){
        wait( [this] { return ! myQueue.empty(); } );  // (2)
        lock();
        auto val = myQueue.front();                    // (4)
        myQueue.pop();                                 // (5)
        unlock();
        return val;
    }

private:
    std::queue<T> myQueue;                            // (3)
};


class Dice {
public:
    int operator()(){ return rand(); }
private:
    std::function<int()> rand = std::bind(std::uniform_int_distribution<>(1, 6),
                                          std::default_random_engine());
};


int main(){
  
    std::cout << '\n';
  
    constexpr auto NumberThreads = 100;
  
    ThreadSafeQueue<int> safeQueue;                      // (7)

    auto addLambda = [&safeQueue](int val){ safeQueue.add(val);          // (8)
                                            std::cout << val << " "
                                            << std::this_thread::get_id() << "; ";
                                          };
    auto getLambda = [&safeQueue]{ safeQueue.get(); };  // (9)

    std::vector<std::thread> addThreads(NumberThreads);
    Dice dice;
    for (auto& thr: addThreads) thr = std::thread(addLambda, dice());

    std::vector<std::thread> getThreads(NumberThreads);
    for (auto& thr: getThreads) thr = std::thread(getLambda);

    for (auto& thr: addThreads) thr.join();
    for (auto& thr: getThreads) thr.join();
  
    std::cout << "\n\n";
   
}

Object Ownership

By Ilya Doroshenko

Since we know the rules of new and delete, namely new allocates and delete destroys, we never really cared about who is responsible for the object. This caused a lot of confusion in the past. For instance, some API codes from Win32 return strings that should be LocalFree()d, like FormatMessage or GetEnvironmentStrings. POSIX, on the other hand, has strdup as a common example of you should free it yourself. This model is confusing because you may have a lot of return statements, before which you should always call free or delete, depending on the operation. However, we have RAII since the very beginning of C++, which adds constructors and destructors. So, in 1998 resourceful people decided to add auto_ptr to the standard.

The premise was simple:

• a simple explicit constructor, that took raw pointer from new
• destroyed by either an explicit release/reset or a destructor on the end of the block

This was the first attempt at a structured cleanup. As time passed, the initial point began to crumble. More issues arose and the question came up: Who owns the data?

Parsing Time Stamps Faster with SIMD Instructions

by Daniel Lemire

You can generate time stamps using any programming language. In C, the following program will print the current time (universal, not local time):

We are interested in the problem of parsing these strings. In practice, this means that we want to ...

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.