New C++ Features in GCC13 -- Marek Polacek

By Blog Staff | Jul 13, 2023 02:31 PM | Tags: None

The latest major version of the GNU Compiler Collection (GCC), 13.1, was released in April 2023. Like every major GCC release, this version brings many additions, improvements, bug fixes, and new features.

New C++ features in GCC 13

by Marek Polacek

From the article:

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 -- Rainer Grimm

By Blog Staff | Jul 11, 2023 11:16 AM | Tags: None

The active object design pattern decouples method execution from method invocation for objects that each reside in their own thread of control.The goal is to introduce concurrency, by using asynchronous method invocation and a scheduler for handling requests.

Active Object

by Rainer Grimm

From the article:

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 -- Bartlomiej Filipek

By Blog Staff | Jul 6, 2023 05:07 PM | Tags: None

A few years ago, I showed an interesting implementation for self-registering classes in factories. It works, but one step might be at the edge of Undefined behavior. Fortunately, with C++20, its new constinit keyword, we can update the code and ensure it’s super safe.

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

by Bartlomiej Filipek

From the article:

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

By Blog Staff | Jul 4, 2023 05:07 PM | Tags: None

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?

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

by Raymond Chen

From the article:

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! -- Kevlin Henney

By Blog Staff | Jul 3, 2023 10:49 AM | Tags: None

Sorting algorithms have been thoroughly studied. Kevlin Henney takes an unexpected paradigm journey into sleep sort.

Need Something Sorted? Sleep On It!

by Kevlin Henney

From the article:

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 Jens Maurer | Jul 3, 2023 02:20 AM | Tags: intermediate c++14

Less overhead for associative container lookup

Modern C++ In-Depth — Transparent Comparisons

by Michael Kristofik

From the article:

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 -- Andreas Fertig

By Blog Staff | Jun 30, 2023 10:40 AM | Tags: None

std::move can allow the efficient transfer of resources from object to to object. Andreas Fertig reminds us that using std::move inappropriately can make code less efficient.

Why You Should Only Rarely Use std::move

by Andreas Fertig

From the article:

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 ③ }; }

Listing 1

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.

Further down in Use, we see ③, a temporary object of S used to initialize obj, also of type S. This is the typical situation where move semantics excels over a copy (assuming the class in question has movable members). The output I expect, and I wanted to show my participants, is:

Type Safe C++ enum Extensions -- Alf Steinbach

By Blog Staff | Jun 28, 2023 07:36 AM | Tags: None

Is it possible to extend a value type in C++? Alf Steinbach describes how to extend enum values.

Type Safe C++ enum Extensions

by Alf Steinbach

From the article:

Consider if an enum like the following,

  enum class Suit{
  spades, hearts, diamonds, clubs };

could be extended like

  enum class Suit_with_joker extends Suit {
    joker };

where

• Suit_with_joker has all the enumerators of Suit plus the joker enumerator; and
• enumerators introduced in Suit_with_joker get integer values following those of Suit; and
• any Suit value is also a Suit_with_joker value.

This would be an example of what I’ll call a value type extension.

The apparently backwards is-a relationship in the last point, where any value of the original type is-a value of the derived type, is characteristic of value type extensions.

C++20 totally lacks support for value type extensions, of enum types or other types.

It’s Great That You Provide Operator Overloads, But It’s Also Nice to Have Names -- Raymond Chen

By Blog Staff | Jun 25, 2023 05:08 PM | Tags: None

Operator overloading. Looks great. Reduces verbosity. Until it doesn’t.

It’s Great That You Provide Operator Overloads, But It’s Also Nice to Have Names

by Raymond Chen

From the article:

Consider this overloaded function call operator:

struct StorageLoader
{
    template<DataType>
    DataType operator()(StorageOptions<DataType> const* options);
};

The idea is that you can use the function call operator on a Storage­Loader object to load data from storage, using a StorageOptions to describe how you want it to be loaded.

Object Lifetime -- Ilya Doroshenko

By Blog Staff | Jun 22, 2023 07:23 AM | Tags: None

Today, we are going to talk about an object. Without further ado, let’s dive deeper!

Object Lifetime

by Ilya Doroshenko

From the article:

What is an object? According to the C++ standard, part 3.9.8 under the name of [basic.types]

 An object type is a (possibly cv-qualified) type that is not a function type, not a reference type, and not a void type.

Now is int i an object? Yes.

Is void* p an object? Still yes, because pointers are types themselves, they are not references.

As we said, references are not types, but what if we declare something like struct S{ int& ref;}; would that be an object type?