Home » Blog » Categories »

C++20 Concepts Applied -- Andreas Fertig

By Blog Staff | Jan 30, 2024 01:29 PM | Tags: None

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...

ACCU Early Bird Tickets and Workshops Now Available -- ACCU

By philsquared | Jan 27, 2024 10:41 AM | Tags: None

logo2024.png

The 2024 ACCU Conference has published workshops and opened Early Bird tickets.

Early-bird tickets and workshops now available

From the article:

At time of writing our Early Bird rates are in effect, but hurry! These will end on 15th February, after which standard rates will apply. As ever the cheapest way to get tickets is to be, or become, an ACCU member - so join up today if you're not already a member!

C++ Online

By philsquared | Jan 25, 2024 10:57 AM | Tags: None

C++ Online is a brand new online C++ conference, including great value training workshops and regular talks, keynotes and lightning talks. The main conference runs from 29th February to 2nd March.

C++ Online, Revisited

From the article:

C++ Online also now has its own website, where you can find all the details, including speakers, workshops and ticket sales.
So go to cpponline.uk now!

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

By John Farrier | Jan 25, 2024 10:55 AM | Tags: None

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.

CopperSpice: Generic vs Meta Programming

By Ansel Sermersheim | Jan 25, 2024 10:54 AM | Tags: None

New video on the CopperSpice YouTube Channel:

Generic vs Meta Programming

by Barbara Geller and Ansel Sermersheim

About the video:

We released a new video which compares Generic and Meta Programming and how they are used in various computer languages like C++, Rust, and Go. In this video we also explain the definition of Template Meta Programming and when TMP is actually Reflection.

Simply using a template does not imply you are doing template meta programming and using a code generator does not mean you have implemented reflection.

Please take a look and remember to subscribe.

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

By Giovanni Dicanio | Jan 24, 2024 12:20 PM | Tags: None

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

By John Farrier | Jan 24, 2024 12:19 PM | Tags: None

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

By Blog Staff | Jan 24, 2024 10:43 AM | Tags: None

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