C++ programmer's guide to undefined behavior: part 5 of 11

By Andrey Karpov | Sep 13, 2024 05:32 AM | Tags: use-after-move undefined behavior ub standard library const

Your attention is invited to the fifth part of an e-book on undefined behavior. This is not a textbook, as it's intended for those who are already familiar with C++ programming. It's a kind of C++ programmer's guide to undefined behavior and to its most secret and exotic corners. The book was written by Dmitry Sviridkin and edited by Andrey Karpov.

C++ programmer's guide to undefined behavior: part 5 of 11

by Dmitry Sviridkin

From the article:

However, all this fuss with removing and adding const anywhere in the code eliminates this set of optimizations. So, a repeated access by a constant reference to the same data member or member function doesn't need to be cached at all. Note. It's worth mentioning that programmers have unrealistic expectations about the compiler optimizing code when they add more const. Here's a good note on the topic: "Why const Doesn't Make C Code Faster".

Qt and Trivial Relocation (Part 5) -- Giuseppe D'Angelo

By Blog Staff | Sep 11, 2024 02:05 PM | Tags: None

In previous posts, we've explored relocation, trivial relocation, and their use in optimizing data structures like vector-like containers. We've also examined how trivial relocation relates to move assignments, enabling further optimization of operations like swaps and algorithms such as std::sort and std::rotate.

Qt and Trivial Relocation (Part 5)

by Giuseppe D'Angelo

From the article:

Is trivial relocation allowed in Standard C++?

That’s probably a question we should have asked as soon as we started this journey. Of course, the answer is no, it is not allowed!

Remember how trivial relocation works: we use memcpy a source object(‘s representation) into some storage, and claim that operation realizes the equivalent of move-constructing the source into that storage, plus destroying the source.

The problem is that one can’t just put data into some storage and pretend that an object exists in there. This is only allowed for a specific set of types, such as trivially copyable types. (Note that if a type is trivially copyable, then Qt automatically considers it trivially relocatable.)

However, as we have discussed, many interesting types (QString, std::vector, std::unique_ptr, …) are not trivially copyable, but they would still benefit from trivial relocatability.

Understanding the inner workings of C++ smart pointers -- Andreas Fertig

By Blog Staff | Sep 9, 2024 02:00 PM | Tags: None

Previously, we explored a basic implementation of unique_ptr in "Understanding the Inner Workings of C++ Smart Pointers - The unique_ptr." Now, let's enhance that model by incorporating a custom deleter, similar to what the Standard Library provides.

Understanding the Inner Workings of C++ Smart Pointers - The Unique_ptr with Custom Deleter

by Andreas Fertig

From the article:

Let's first establish why somebody would want a custom deleter.

One example is that the object was allocated via a local heap, and such must be returned by calling the corresponding deallocation function.

Another example is fopen. This function returns a FILE* object that you are supposed to delete by calling fclose. A classic job for a unique pointer. But you cannot call delete on the FILE pointer.

Here are two examples of using a unique_ptr with a custom deleter.

void MyDeleter(Object* ptr)
{
  delete ptr;
}

unique_ptr<Object> alfred{new Object{}};
static_assert(sizeof(alfred) == sizeof(void*));

unique_ptr<Object, decltype(MyDeleter)> robin{new Object{}, &MyDeleter};
static_assert(sizeof(robin) == sizeof(void*) * 2);

Oh yes, the first object, alfred, doesn't provide a custom deleter. Only robin does. Behind the curtains, both do. Let's look at a modified unique_ptr implementation that handles the custom deleter case.

Opaque Pointer Pattern in C++ -- Daniel Sieger

By Blog Staff | Sep 5, 2024 01:55 PM | Tags: None

After reading this article, you should understand the basics of the opaque pointer pattern and how you can implement it using std::unique_ptr. I also gave some hints on when it is appropriate to use it and when maybe not.

Opaque Pointer Pattern in C++

by Daniel Sieger

From the article:

The basic problem is that C++ class declarations expose private details of the class. Private member functions and data members need to be declared in the header. Here’s an example for illustration:

// Point.h

class Point
{
public:
  Point(float x, float y);
  float x();
  float y();

private:
  float x_;
  float y_;
};

While users of this class don’t have direct access to the private data members x_ and y_, there is still a dependency: If you change the private implementation details of Point, all other compilation units that include Point.h know about the change and need to be re-compiled.

This only gets worse for more complex dependency chains, e.g., when there are dependencies to other classes internal to the module that need to be included. To a certain degree, this can be dealt with by using forward declarations. However, at the end of the day there is an information leak: Private implementation details are leaking to clients. This goes directly against the idea of information hiding.

The opaque pointer pattern helps to deal with this problem.

Enum Class Improvements for C++17, C++20 and C++23 -- Bartlomiej Filipek

By Blog Staff | Sep 3, 2024 01:51 PM | Tags: None

The evolution of the C++ language continues to bring powerful features that enhance code safety, readability, and maintainability. Among these improvements, we got changes and additions to enum class functionalities across C++17, C++20, and C++23. In this blog post, we’ll explore these advancements, focusing on initialization improvements in C++17, the introduction of the using enum keyword in C++20, and the std::to_underlying utility in C++23.

Enum Class Improvements for C++17, C++20 and C++23

by Bartlomiej Filipek

From the article:

Before diving into the enhancements, let’s briefly recap what enum class is. An enum class (scoped enumeration) provides a type-safe way of defining a set of named constants. Unlike traditional (unscoped) enums, enum class does not implicitly convert to integers or other types, preventing accidental misuse. Here’s a basic example:

#include <iostream>

enum class Color {
    Red,
    Green,
    Blue
};

int main() {   
    Color color = Color::Red;

    if (color == Color::Red)
        std::cout << "The color is red.\n";

    color = Color::Blue;

    if (color == Color::Blue)
        std::cout << "The color is blue.\n";

    // std::cout << color; // error, no matching << operator
    // int i = color;      // error: cannot convert
}

The Difference Between Undefined Behavior and Ill-formed C++ Programs -- Raymond Chen

By Blog Staff | Aug 30, 2024 01:48 PM | Tags: None

The C++ language has two large categories of “don’t do that” known as undefined behavior and ill-formed program. What’s the difference?

The Difference Between Undefined Behavior and Ill-formed C++ Programs

by Raymond Chen

From the article:

The C++ language has two large categories of “don’t do that” known as undefined behavior and ill-formed program. What’s the difference?

Undefined behavior (commonly abbreviated UB) is a runtime concept. If a program does something which the language specified as “a program isn’t allowed to do that”, then the behavior at runtime is undefined: The program is permitted by the standard to do anything it wants. Furthermore, the effect of undefined behavior can go backward in time and invalidate operations that occurred prior to the undefined behavior. It can do things like execute dead code. However, if your program avoids the code paths which trigger undefined behavior, then you are safe.

Once More About the Rule of 5 -- Sandor Dargo

By Blog Staff | Aug 27, 2024 01:40 PM | Tags: None

In a recent talk at C++OnSea, Arne Mertz highlighted common misuses of guidelines, including the Rule of Five. This discussion prompted me to reflect on a recurring pattern I've observed in C++ classes that explicitly default constructors and destructors, leading to unexpected behaviors with move semantics.

Once More About the Rule of 5

by Sandor Dargo

From the article:

Let’s first repeat what the rule of 5 says.

The Rule of Five tells us that if we need to define any of a copy constructor, copy assignment operator, move constructor, move assignment operator or destructor then we usually need to define all five.

Fair enough.

Have you ever seen classes where the default constructor and destructor are explicitly defaulted? Like this?

First of all, that’s not the best idea. You can simply remove them. But let’s assume that you cannot remove the user-provided destructor for some reason. Maybe it’s not defaulted and it does something.

What does the famous Hinnant table tell us?

C++ programmer's guide to undefined behavior: part 4 of 11

By Andrey Karpov | Aug 23, 2024 07:45 AM | Tags: undefined behavior ub tuples lifetime extension lifetime lambda function

Your attention is invited to the fourth part of an e-book on undefined behavior. This is not a textbook, as it's intended for those who are already familiar with C++ programming. It's a kind of C++ programmer's guide to undefined behavior and to its most secret and exotic corners. The book was written by Dmitry Sviridkin and edited by Andrey Karpov.

C++ programmer's guide to undefined behavior: part 4 of 11

by Dmitry Sviridkin

From the article:

In the C++98, the committee made a terrible decision that seemed reasonable at the time. They created a specialization for std::vector<bool>. Normally, sizeof(bool) == sizeof(char), but one bit is enough for bool. However, 99.99% of all possible platforms can't address memory one bit at a time. Let's pack bits in vector<bool> and store CHAR_BIT (usually 8) boolean values in one byte (char) for more efficient memory utilization. As a result, one needs to work with std::vector<bool> in a very special way...

What's so hard about constexpr allocation? -- Barry Revzin

By Blog Staff | Aug 21, 2024 05:21 PM | Tags: None

Before C++20, constant evaluation couldn't handle allocations, causing any such attempts to fail. This changed with C++20, which introduced the ability to allocate memory during constant evaluation, although with strict limitations requiring deallocation during the same evaluation period. Despite these advancements, certain operations, such as declaring a constexpr std::vector, remain impossible, with the goal of this blog post being to explore why these limitations persist.

What's so hard about constexpr allocation?

by Barry Revzin

From the article:

Before C++20, we couldn’t have any allocation during constant evaluation at all. Any attempt to do so would fail the evaluation — it would no longer be constant.

In C++20, as a result of P0784R7, that changed. Finally we could do allocation during constant evaluation. However, this evaluation was extremely limited. Specifically, any allocation that happens must be deallocated during that constant evaluation.

This opened the door to a wide range of operations that weren’t possible before. We can now have local std::strings and std::vector<T>s! Those just work!

But we still cannot just declare a constexpr std::vector:

#include <vector> 
constexpr std::vector<int> v = {1, 2, 3}; // error 

And we cannot even declare a local constexpr std::vector in a consteval function:

#include <vector> 
consteval auto f() -> int { constexpr std::vector<int> v = {4, 5, 6}; // still error 
return v.size(); 
} 

This limitation still remains in C++23 and could very well still remain in C++26. The goal of this blog post is to explain why we haven’t just solved this problem already.

What to do if you don't want a default constructor? -- Sandor Dargo

By Blog Staff | Aug 13, 2024 04:38 PM | Tags: None

Do we need a default constructor? What does it mean to have a default constructor? What happens if we don’t have one? Those are the questions we are going after in this article.

What to do if you don't want a default constructor?

by Sandor Dargo

From the article:

A default constructor is a constructor that takes no arguments and initializes - hopefully - all the members with some default values. If you define no constructors at all, it’ll even be generated for you.

Do we need default constructors?

It really depends. Let’s first approach this question from a design point of view. Does it make sense to represent an object where the members are default initialized?

If you represent a tachograph, it probably makes sense to have such a default state where all the counters are initialized to zero.

The tachograph is the device that records driving times and rest periods as well as periods of other work and availability taken by the driver of a heavy vehicle.

On the other hand, if you represent a person or a task identifier - which inspired me to write this article - it doesn’t. A person with an empty name or a task ID with an empty ID doesn’t make much sense.

Well, that’s the case from a design point of view. What about the technical aspects? What happens if we don’t have a default constructor?