Articles & Books

C++20 Concepts Applied -- Andreas Fertig

me.pngIn this post, we'll dive into implementing this technique in C++17 and then explore how it evolves with the application of C++20 concepts to the code. The goal is to simplify the code by eliminating the need for cumbersome constructs like enable_if and introduce further improvements in C++23.

C++20 Concepts Applied - Safe Bitmasks using Scoped Enums

by Andreas Fertig

From the article:

In 2020 I wrote an article for the German magazine iX called Scoped enums in C++. In that article, I shared an approach of using class enums as bitfields without the hassel of having to define the operators for each enum. The approach was inspired by Anthony William's post Using Enum Classes as Bitfields.

Today's post aims to bring you up to speed with the implementation in C++17 and then see how it transforms when you apply C++20 concepts to the code.

One operator for all binary operations of a kind
The idea is that the bit-operators are often used with enums to create bitmasks. Filesystem permissions are one example. Essentially you want to be able to write type-safe code like this:

using Filesystem::Permission;
Permission readAndWrite{Permission::Read | Permission::Write};

The enum Permission is a class enum, making the code type-safe. Now, all of you who once have dealt with class enums know that they come without support for operators. Which also is their strength. You can define the desired operator or operators for each enum. The issue here is that most of the code is the same. Cast the enum to the underlying type, apply the binary operation, and cast the result back to the enum type. Nothing terribly hard, but it is so annoying to repeatedly type it.

Anthony solved this by...

The decorator pattern: From basic to advanced concepts in C++ -- John Farrier

The Decorator Pattern stands out for its unique ability to dynamically add new functionalities to objects without altering their structure.

The decorator pattern: From basic to advanced concepts in C++

John Farrier

From the article:

The Decorator Pattern allows developers to seamlessly decorate or wrap objects with new behaviors or responsibilities, ensuring that the enhancements are scalable, manageable, and, most importantly, interchangeable. This capability is crucial in an era where software requirements are constantly evolving, demanding adaptable and resilient systems to change.

Let’s illustrate this with a basic C++ example. Consider a window in a user interface as the Component. You want to add functionalities like scrollbars or a border without redesigning the window itself.

Here’s a simplified version of how you might implement this:

class Window { // Component
public:
    virtual void draw() = 0;
    virtual ~Window() {}
};

class SimpleWindow : public Window { // Concrete Component
public:
    void draw() override {
        // Draw the window
    }
};

class WindowDecorator : public Window { // Decorator
protected:
    Window* window;
public:
    WindowDecorator(Window* wnd) : window(wnd) {}
    void draw() override {
        window->draw(); // Delegate to the component
    }
};

class ScrollbarWindow : public WindowDecorator { // Concrete Decorator
public:
    ScrollbarWindow(Window* wnd) : WindowDecorator(wnd) {}
    void draw() override {
        WindowDecorator::draw(); // Draw the window
        drawScrollbar(); // Add scrollbar
    }
private:
    void drawScrollbar() {
        // Draw the scrollbar
    }
};


In this example, SimpleWindow is a Concrete Component that can be decorated with additional features. WindowDecorator is a Decorator that holds a reference to a Window object and delegates the draw operation to it. ScrollbarWindow is a Concrete Decorator that adds a scrollbar to the window.

Subtle C++ Compiler Error with std::optional and the Conditional Operator -- Giovanni Dicanio

An example of writing clear code with good intention, but getting an unexpected C++ compiler error:

Subtle C++ Compiler Error with std::optional and the Conditional Operator

by Giovanni Dicanio

From the article:

I was asked: “What’s the problem here? Are there limitations of using the {} syntax to specify nothing?”

This is a good question. So, clearly, the C++ compiler didn’t interpret the {} syntax as a way to default-initialize the std::optional in case the string was not empty (i.e. the second “branch” in the conditional ternary operator).

A first step to help the C++ compiler figuring out the programmer’s intention could be to be more explicit. So, instead of using {}, you can try and use the std::nullopt constant, which represents an optional that doesn’t store any value. [...]

[...]

P.S. I’m not a C++ “language lawyer”, but it would be great if the C++ language could be extended to allow the original simple code to just work.

IEEE Floating Point and the Radar Range Equation in C++ -- John Farrier

The implementation of mathematical equations demands a keen awareness of the computational environment. This article uses a practical example of implementing the Radar Range Equation, a cornerstone formula in radar technology, to illustrate the importance of considering IEEE floating point representation in C++ for accurate and reliable computations.

Engineering Mathematics: A Focus on IEEE Floating Point and the Radar Range Equation in C++

by John Farrier

From the Article:

The nature of IEEE floating-point numbers in C++ brings certain challenges, especially when dealing with large or small numbers and operations like multiplication and division. Precision issues can significantly impact the accuracy of computations, making it essential to adapt the implementation strategy.

 

The Double Life of Objects -- Andrzej Krzemieński

doublelife-1.pngIn the world of C++, the concept of object lifetime and constness can become a bit hazy when copy elision, a popular optimization technique, comes into play. In this article, Andrzej Krzemieński explores the intricacies of object lifetimes and constness, using a class called Rng to illustrate how objects can appear const in one context and non-const in another due to copy elision. He'll also delve into the motivations behind C++'s handling of const objects and how it impacts program behavior.

The Double Life of Objects

by Andrzej Krzemieński

From the article:

Some common knowledge: the lifetime of the object starts when its initialization is complete. Based on this we can get some further expectations: an object becomes const only after its initialization is complete. But this lifetime property of objects becomes blurred when copy elision comes into play. When a copy is elided, we have a situation where we would otherwise have two objects, each initialized separately, but now they are blended into one, its life time spanning across the caller and the calle, which has a number of surprising effects, receiving two initializations being one of them.

In the following examples we will use class Rng that is quite small but convincing: you define a class when you need to maintain the invariant. Our class represents a range of integers between the minimum and maximum values.

doublelife-1.png

Now, let’s try to use it in a somewhat artificial program:

doublelife-2.png

Use SIMD: Save The Planet -- Andrew Drakeford

simddrake.pngWriting efficient code is challenging but worthwhile. Andrew Drakeford demonstrates how SIMD (Single Instruction Multiple Data) can reduce your carbon footprint.

Use SIMD: Save The Planet

by Andrew Drakeford

From the article:

Some sources claim that data centres consumed 2.9% of the world’s electricity in 2021 [Andrae15]. With the recent sharp increase in energy prices, many firms became aware of this cost. Additionally, trends in AI use and the near-exponential growth in both network and data services projected over the next few years [Jones18] suggest that this situation will only get worse.

A data centre’s single purpose is to run our software (not heat the planet). But what if the processing cores that our software runs on have a unique, often unused, feature that would enable them to do the work several times faster? Would this also mean several times more efficiently? This feature is SIMD (Single Instruction Multiple Data).

SIMD is a parallel computing technology that allows processors to perform the same operation on multiple data elements simultaneously. By using SIMD instructions, a single CPU instruction can operate on multiple data elements in a single clock cycle. For example, with 256-bit SIMD registers, it is possible to process eight 32-bit floating-point numbers or sixteen 16-bit integers in parallel. This leverages the data-level parallelism inherent in many algorithms, such as mathematical computations, image processing, audio processing, and simulations. Figure 1 illustrates the element-wise addition of two sets of numbers using the SSE2, AVX2 and AVX512 instructions sets.


 

SIMD instructions use vector registers, which can hold multiple data elements. These registers allow the CPU to apply a single instruction to all the elements simultaneously, thus reducing the instruction count. Consequently, SIMD can provide a substantial speedup for tasks that exhibit regular and parallelizable data processing patterns.