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

By Andrey Karpov | Nov 11, 2024 10:38 AM | Tags: undefined behavior static inline reserved names odr null pointer dereferencing nrvo

Your attention is invited to the ninth 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 9 of 11

by Dmitry Sviridkin

From the article:

And you could write it only in C++. In C, however, this mess has been forbidden (see 6.5.3.2, note 104). Also, you can't use the dereference operator on invalid and null pointers anywhere in C. Meanwhile, C++ has its own, special way of doing things. These weird examples were built in constexpr context (let me remind you that UB is forbidden there, and the compiler checks for it).

Implementing Trivial Relocation in Library -- Barry Revzin

By Blog Staff | Nov 6, 2024 11:05 AM | Tags: None

One of the reasons that I’m excited for Reflection in C++ is that it can permit you to implement, as a library, many things that previously required language features. In this post, I’m going to walk through implementing P2786R8 (“Trivial Relocatability For C++26”).

Implementing Trivial Relocation in Library

by Barry Revzin

From the article:

The goal here is not to say that the design is right or wrong (although the syntax certainly is suspect), but rather to show the kinds of things that reflection can solve.

We’ll just go straight to the wording and translate it into code as we go:

Trivially Relocatable Types

Scalar types, trivially relocatable class types (11.2 [class.prop]), arrays of such types, and cv-qualified versions of these types are collectively called trivially relocatable types.

This sure sounds like a type trait! Except in the world of reflection, those are just functions. How would we implement such a thing? We could start by doing this:

consteval auto is_trivially_relocatable(std::meta::info type)
    -> bool
{
    type = type_remove_cv(type);

    return type_is_scalar(type)
        or (type_is_array(type)
            and is_trivially_relocatable(
                type_remove_all_extents(type)
            ))
        or is_trivially_relocatable_class_type(type);
}

This is a fairly literal translation, where is_trivially_relocatable_class_type is something to be written shortly. But one interesting thing about the type_remove_all_extents type trait (i.e. std::remove_all_extents) is that it also works for non-array types, just returning back the same type. 

The Publish Pattern -- Lucian Radu Teodorescu

By Blog Staff | Nov 1, 2024 11:02 AM | Tags: None

How do you minimise locking between producers and consumers? Lucian Radu Teodorescu describes a common, but currently undocumented, design pattern. Design patterns can help us reason about code. They are like algorithms that are vaguely defined in the code. Once we recognise a pattern, we can easily draw conclusions about the behaviour of the code without looking at all the parts. Patterns also help us when designing software; they are known solutions to common problems.

In this article, we describe a concurrency pattern that can’t be found directly in any listing of concurrency patterns, and yet, it appears (in one way or another) in many codebases. It is useful when we have producers and consumers that run continuously, and we want to minimise the locking between them.

The Publish Pattern

by Lucian Radu Teodorescu

From the article:

Let’s say we have an open-world game. As the player walks through the world, we load the data corresponding to the regions around the player. We have two types of workloads in our scenario: one for loading the data and another for displaying the loaded data. For the sake of our discussion, let’s say that each of these two activities is bound to a thread.

The problem we are trying to solve is how to structure the passing of data (let’s call this document) from the loading thread (producer) to the rendering thread (consumer). This is analogous to the classical producer-consumer problem [Wikipedia-1], but it has some interesting twists. Let’s try to outline the requirements of the problem:

• (R1) The producer is constantly producing new versions of the document.
• (R2) The consumer is constantly consuming document data.
• (R3) The consumer will use the latest version of the document.

Please note that we are discussing multiple versions of the document. In our example, the loading thread will produce different documents depending on the position of the player, and the rendering thread will display the latest document, corresponding to the player’s most recent position.

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

By Andrey Karpov | Nov 1, 2024 05:34 AM | Tags: undefined behavior noexcept infinite loops halting problem garbage collector buffer overflow

Your attention is invited to the eighth 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 8 of 11

by Dmitry Sviridkin

From the article:

To avoid issues, use conditional noexcept always and everywhere and carefully check every function you use. Or don't use noexcept at all. In the second case, however, it's worth remembering that both move operations and swap should be marked as noexcept (and really be noexcept!) to effectively work with standard containers. Don't forget to write negative tests. You may miss a false noexcept and get std::terminate in the release build without them.

Smart Pointers and the Pointer to Implementation Idiom -- Andreas Fertig

By Blog Staff | Oct 28, 2024 10:31 AM | Tags: None

A post I wrote back in 2023 When an empty destructor is required resulted in feedback that I'd like to address in today's post.

Smart Pointers and the Pointer to Implementation Idiom

by Andreas Fertig

From the article:

In the 2023 post, I briefly mentioned PImpl idiom. I did not intend to make it the theme of the post. However, I got various questions about PImpl and smart pointers.

The goal of PImpl is to hide implementation details from clients. Since you can declare a pointer of an unknown class, you can shift the entire implementation of such an anonymous class into a .cpp file. That way, no client can see any details. Another benefit is that changes to that .cpp file result in only minor recompiles. Maintaining the same in a header file would cause all .cpp files, including this header, to recompile. At least the speed-up part is since C++20's modules are no longer necessary. And as long as you don't want to hide classified implementation in the .cpp file modules, it also gives you the ability to mark constructs as private.

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

By Andrey Karpov | Oct 26, 2024 01:45 PM | Tags: undefined behavior std::string_view std::string std::ranges std::aligned_storage null-terminated strings

Your attention is invited to the seventh 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 7 of 11

by Dmitry Sviridkin

From the article:

In the early '70s, Ken Thompson, Dennis Ritchie, and Brian Kernighan worked on the first versions of C and Unix. They made a decision that resonates with pain, suffering, bugs, and inefficiency today, 50 years later. They decided that developers were to write strings—variable-length data—in a sequence that terminated with a null character. Assembly has it, and C should have it too, if people call it "high-level assembly"! After all, the poor old PDP has limited memory: it's better to have one extra byte per string than 2, 4, or even all 8 bytes (depending on the platform) to store the size... Nah, it's better to have a byte at the end! But even other languages store a size, a reference, or a pointer to the data...

The Definitive Guide to std::expected in C++ -- John Farrier

By John Farrier | Oct 23, 2024 12:05 PM | Tags: None

std::expected is a powerful feature introduced in C++23 that offers a modern, type-safe alternative to traditional error-handling methods.  std::expected allows developers to represent a value or an error in a single object, simplifying the handling of success and failure scenarios in a clean and readable way.

The Definitive Guide to std::expected in C++

John Farrier

From the article:

std::expected is an addition to the C++ standard library that provides a way to return and propagate errors without using exceptions. It represents a value or an error and is similar to the Result type in Rust. This guide covers its use, benefits, and comparison with other error handling techniques, helping developers to write more robust and readable code.

Passing C++ STL Strings vs. String Views at the Windows C API Boundary -- Giovanni Dicanio

By Giovanni Dicanio | Oct 23, 2024 11:57 AM | Tags: None

A common question that is often asked is whether C++ STL string objects (like std::string/wstring) or string views (e.g. std::wstring_view) should be passed as string parameters at Windows C-interface API boundaries. The following articles tries to shed some light on this subject, answering that question:

Passing C++ STL Strings vs. String Views as Input Parameters at the Windows C API Boundary

by Giovanni Dicanio

From the article:

Passing STL std::[w]string objects at Win32 API boundaries is common for C++ code that calls into Win32 C-interface APIs. When is it safe to pass *string views* instead?

(...) the code will work fine. In fact, the wstring::c_str() method is guaranteed to return a null-terminated C-style string pointer.

On the other hand, if you pass a string view like std::wstring_view in that context, you’ll likely get some subtle bugs! Try experimenting with the above API and something like “Connie is learning C++” and string views!

Code Generation in Rust vs C++26 -- Barry Revzin

By Blog Staff | Oct 22, 2024 10:30 AM | Tags: None

Exploring how different languages solve the same problem often reveals interesting contrasts, especially when it comes to implementing powerful features like reflection. While C++26 aims to introduce introspection and code generation via P2996 and P3294, Rust’s approach using its derive macros offers a mature solution for code generation, even without introspection, highlighting different philosophies in language design and their practical applications.

Code Generation in Rust vs C++26

by Barry Revzin

From the article:

One of the things I like to do is compare how different languages solve the same problem — especially when they end up having very different approaches. It’s always educational. In this case, a bunch of us have been working hard on trying to get reflection — a really transformative language feature — into C++26. Fundamentally, reflection itself can be divided into two pieces:

1. Introspection — the ability to ask questions about your program during compilation
2. Code Generation — the ability to have your code write new code

P2996 (Reflection for C++26) is the (huge) core proposal that fundamentally deals with the first problem, along with setting the foundation for being able to extend this feature in lots of different directions in the future, including generation (for which our design is P3294). But introspection, while valuable, is only half of the piece. Andrei Alexandrescu went so far as to claim in his CppCon talk that introspection without generation is useless.

Synchronization Primitives in C++20 -- Shivam Kunwar

By Blog Staff | Oct 17, 2024 10:20 AM | Tags: None

In C++20, the standard library introduced new synchronization primitives: std::latch and std::barrier. These are the utilities designed to coordinate between concurrent threads.

Synchronization Primitives in C++20

by Shivam Kunwar

From the article:

What is a synchronization primitive?

In concurrent programming, synchronization primitives are the fundamental tools that help in managing the coordination, execution order, and data safety of multiple threads or processes that run concurrently.

Briefly said, they ensure that:

• multiple threads don’t simultaneously execute some specific segment of code (a “critical section”)
• the program and the data remain in a consistent state
• deadlocks (where threads wait indefinitely for resources) and race conditions (where the outcome depends on the timing of accessing the shared data by a thread) are prevented or managed

There are multiple synchronization primitives in C++; for example, mutual exclusion, condition variables, atomic operations, locking mechanisms, etc.

In C++20, we have two additional synchronization primitives: latches and barriers.

Let’s discuss both of them.

std::latch

A std::latch is a synchronization primitive that permits a certain number of count_down operations (decrements) before allowing one or more threads to pass the wait point. A latch cannot be reused once its internal counter reaches zero.

How do we use a latch?

• A std::latch object is created with an initial count.
• Multiple threads can decrement this count using the count_down method.
• Threads can call wait, which block until the internal count of the latch reaches zero.