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? 

Dealing with Mutation: Guarded Suspension -- Rainer Grimm

By Blog Staff | Jun 20, 2023 10:35 AM | Tags: None

Guarded Suspension applies a unique strategy to deal with mutation. It signals when it is done with its modification.

Dealing with Mutation: Guarded Suspension

by Rainer Grimm

From the article:

The guarded suspension basic variant combines a lock and a precondition that must be satisfied. If the precondition is not fulfilled, that checking thread puts itself to sleep. The checking thread uses a lock to avoid a race condition that may result in a data race or a deadlock.

Various variants of the Guarded Suspension exist:

• The waiting thread can passively be notified about the state change or actively ask for the state change. In short, I call this push versus pull principle.
• The waiting can be done with or without a time boundary.
• The notification can be sent to one or all waiting threads.

I present in this post only the rough idea. Let me start with the push principle.

You often synchronize threads with a condition variable or a future/promise pair. The condition variable or the promise sends the notification to the waiting thread. A promise has no notify_one or notify_all member function. Typically, a valueless set_value call is used to ...

C++17’s Useful Features for Embedded Systems -- Çağlayan Dökme

By Blog Staff | Jun 16, 2023 10:26 AM | Tags: None

Recently, our team at Meteksan Defense is upgrading its development environment to use newer versions of many tools and programming languages. One of the more difficult transitions has been the upgrade of our C++11 code base to C++17 for our embedded applications.

In this article, I will be showing some features of C++17 that can also be helpful in the embedded world.

C++17’s Useful Features for Embedded Systems

by Çağlayan Dökme

From the article:

C++14 had smaller upgrades compared to the ones we saw when migrating to C++11 from C++03. Hence, there are only a few features in C++14 that you can use in an embedded system.

Binary Literals

If you are frequently dealing with bitwise operations and modifying registers, you will love these literals. Some compilers had extensions that support such literals, but now they have a place in the actual standard.

uint8_t a = 0b110; // == 6 
uint8_t b = 0b1111'1111; // == 255 

Constraint relaxed constexpr**

With C++14, the syntax you can use in a constexpr function is expanded. Check out this post on StackOverflow. The constexpr is beneficial in the embedded world since...

On Writing Functions That Accept Any Specialization of a C++ Template Type -- Raymond Chen

By Blog Staff | Jun 15, 2023 10:18 AM | Tags: None

Suppose you want to write a template function that accepts any specialization of std::vector? What may work today may not work tomorrow.

On Writing Functions That Accept Any Specialization of a C++ Template Type

by Raymond Chen

From the article:

Suppose you want to write a template function that accepts any specialization of std::vector. Your first try would probably be something like this:

template<typename Value>
void accept_any_vector(std::vector<Value> v);

However, this does not actually accept any vector specialization. There is a second template argument for the allocator, which has a default value that nearly everyone uses. But if somebody has a vector with a custom allocator, then your function won’t match.

Dealing with Mutation: Thread-Safe Interface -- Rainer Grimm

By Blog Staff | Jun 13, 2023 12:01 PM | Tags: None

I continue my journey with concurrency patterns in today's post. The Thread-Safe Interface fits very well when the critical sections are just objects.

Dealing with Mutation: Thread-Safe Interface

by Rainer Grimm

From the article:

The naive idea to protect all member functions of a class with a lock causes, in the best case, a performance issue and, in the worst case, a deadlock.

A Deadlock

The small code snippet has a deadlock.

struct Critical{
    void memberFunction1(){
        lock(mut);
        memberFunction2();
    ...
}

void memberFunction2(){
        lock(mut);
        ...
    }

    mutex mut;
};

Critical crit;
crit.memberFunction1();

Calling crit.memberFunction1 causes the mutex mut to be locked twice. For simplicity reasons, the lock is a scoped lock. Here are the two issues: