8 More C++23 Examples -- Bartlomiej Filipek

By Blog Staff | Feb 17, 2025 03:37 PM | Tags: None

In this article, you’ll see eight larger examples that illustrate the changes in C++23.

8 More C++23 Examples

by Bartlomiej Filipek

From the article:

C++23 brings a ton of cool features, as you can see in my two previous articles (here and here). So far, we explored each new addition one by one, but I’d like to share more examples that combine multiple features.

Here we go:

1. std::ranges::to<> 

The ranges::to<> feature allows you to convert ranges into containers easily:

In C++, failure to meet the requirements does not always mean that you fail -- Raymond Chen

By Blog Staff | Feb 13, 2025 03:26 PM | Tags: None

When tasked with diagnosing why a pointer passed through a pipeline emerged offset from its original value, I discovered an interesting culprit: the misuse of a wrapper function around SubmitWork. While the wrapper aimed to simplify usage by allowing both raw pointers and references to standard layout types, it inadvertently caused ambiguous overload resolution, leading to incorrect behavior. This analysis explores how the issue arose, the debugging process, and improvements to ensure robust and predictable pointer handling in similar scenarios.

In C++, failure to meet the requirements does not always mean that you fail if you don’t meet the requirements

by Raymond Chen

From the article:

I was asked to help debug a problem where a pointer passed to a function was received slightly offset from the original value. The pointer is passed as an opaque parameter and is supposed to be spit out the other end of a pipeline. But somehow, the value that came out the other end was slightly different.

For expository purposes, let’s say that the underlying function we’re trying to call is this one.

void SubmitWork(HWORKER worker, int commandCode, void* param);

You call Submit­Work with a worker, a command code, and a raw pointer to some data that depends on the command code.

The developer sent me some debugging output that showed that the function that handled the command code received a different pointer from what was passed. One possibility is that there was a bug in the library that resulted in it unintentionally modifying the final pointer parameter, but this seemed unlikely, since the value should be opaque to the library. I was able to get on a video call with the developer to watch them step through the code, and that’s where I noticed something interesting.

 

ADL – Avoid Debugging Later -- Coral Kashri

By Blog Staff | Feb 11, 2025 03:18 PM | Tags: None

Back in the day, being a witch was considered a grave crime. Today, we’re diving into one of C++’s lesser-known spells: ADL (Argument-Dependent Lookup). 

ADL – Avoid Debugging Later

by Coral Kashri

From the article:

But before we explore this arcane magic, you must heed a warning—black magic comes with consequences. ADL is particularly treacherous, often leading to frustrating and hard-to-debug issues. Whenever possible, it’s wise to avoid casting this spell unless absolutely necessary.

Ingredients

Every spell needs ingredients, this time the only ingredients you need are a C++ compiler and a function that accepts at least one parameter, but there is a try catch, the parameter type has to belong to the same namespace of the function.

This spell works in shadows—you must look closely to uncover its effect.

std::cout << "Can you see me?";

Should the spell have passed you by, I’ll summon its power again for your eyes:

std::vector<int> a{1}, b{2};
swap(a, b);

If the spell’s effect remains elusive, let’s summon the entire code for you to see:

#include <vector>

int main() {
    std::vector<int> a{1}, b{2};
    swap(a, b);
    return 0;
}

21st Century C++ -- Bjarne Stroustrup

By Bjarne Stroustrup | Feb 10, 2025 12:18 PM | Tags: None

It is now 45+ years since C++ was first conceived. As planned, it evolved to meet challenges, but many developers use C++ as if it was still the previous millennium. This is suboptimal from the perspective of ease of expressing ideas, performance, reliability, and maintainability.

21st Century C++

by Bjarne Stroustrup

About the article:

Here, I present the key concepts on which performant, type safe, and flexible C++ software can be built: resource management, life-time management, error-handling, modularity, and generic programming. At the end, I present ways to ensure that code is contemporary, rather than relying on outdated, unsafe, and hard-to-maintain techniques: guidelines and profiles.

Serialization by contract -- Alex Marmer

By Alex Marmer | Feb 10, 2025 12:10 PM | Tags: None

Alex shows in his small framework a different approach for serialization of data structures.

Serialization by contract

By Alex Marmer

From the article:

In any project, when a function is created for serialization, another function is created for unserialization.

Serialization by contrast uses another approach - a contract with name and data structures is declared, and then serialization and unserialization of the data are automatic.

Contracts for C++ explained in 5 minutes -- Timur Doumler

By Timur Doumler | Feb 10, 2025 12:05 PM | Tags: None

In this article, we briefly explain everything you need to know to get started with Contracts as proposed for C++26 in P2900.

Contracts for C++ explained in 5 minutes

by Timur Doumler

From the article:

With P2900, we propose to add contract assertions to the C++ language. This proposal is in the final stages of wording review before being included in the draft Standard for C++26.

It has been suggested by some members of the C++ standard committee that this feature is too large, too complicated, and hard to teach. As it turns out, the opposite is true: contract assertions are actually very simple and can be explained in just five minutes. In this blog post, we will do exactly this!

VS Code with MS C/C++ Extension: A Confusing UI Design Choice -- Giovanni Dicanio

By Giovanni Dicanio | Feb 9, 2025 12:28 PM | Tags: None

I wanted to use VS Code with the MS C/C++ Extension for some C++ teaching. In the process, I discovered that setting the C++ language standard to build your C++ code is not as easy and intuitive as one would expect. I discussed the details in this article:

VS Code with MS C/C++ Extension: A Confusing UI Design Choice

by Giovanni Dicanio

From the article:

I pressed Ctrl+Shift+P, selected C/C++ Edit Configurations (UI), and in the C/C++ Configurations page, selected c++20 for the C++ standard.

Then I pressed F5 to start a debugging session, preceded by a build process, and saw that the build process failed.

I took a look at the error message in the terminal window, and to my surprise the error messages were telling me that some libraries (like <span>) were available only with C++20 or later. But I had just selected the C++20 standard a few minutes ago!

Inside STL: The atomic shared_ptr -- Raymond Chen

By Blog Staff | Feb 7, 2025 03:16 PM | Tags: None

The C++20 standard introduced a specialization of std::atomic for shared pointers: std::atomic<shared_ptr<T>>. How does it work?

Inside STL: The atomic shared_ptr

by Raymond Chen

From the article:

Recall that a normal shared_ptr consists of two pointers: A stored pointer that the shared_ptr returns when you call get() and a pointer to a control block which holds the strong reference count, the weak reference count, and a pointer to the managed object.

The atomic version of the shared_ptr has the same layout, with one change: The bottom two bits of the pointer to the control block are used as flags.

Exercise: Why use the control block pointer instead of the stored pointer to store the flags?

Both the glibc++ libstdc++ and msvc implementations use the bottom bit of the control block pointer as a lock bit: Before performing an operation on the atomic shared pointer, the implementation atomically sets the lock bit to indicate that an atomic operation is in progress. If anybody tries to set the lock bit and finds that it’s already set, they wait for bit to clear. When the owner of the lock bit completes the atomic operation, it clears the lock bit, allowing any waiting threads to proceed.

The difference between libstdc++ and msvc is how they wait for the lock bit to clear.

How frivolous use of polymorphic allocators can imbitter your life

By Andrey Karpov | Feb 7, 2025 05:03 AM | Tags: None

Do you want to stay ahead of the curve and start to use polymorphic allocators in your projects? Are you undeterred even by the cost of virtual calls? If so, it's time to talk about the nuances with a lifetime and why you can't just replace containers with analogs from the 'pmr' namespace.

How frivolous use of polymorphic allocators can imbitter your life

by Grigory Semenchev

From the article:

The developers' prayers have been answered! Starting with C++17, you can use polymorphic allocators. Their idea is a little different from what we need. What is important is that they allow you to specify a buffer from which the allocator will take memory. Such a buffer is called a resource, and it must be inherited from std::memory_resource. It's also important that C++17 introduced several standard resources. Let's examine std::unsynchronized_pool_resource as an example. I should admit that all options mentioned in this article mostly apply to all standard library resources.

C++26: Delete with a Reason -- Sandor Dargo

By Blog Staff | Feb 5, 2025 03:12 PM | Tags: None

Let’s start exploring C++26 with a simple but useful change. Thanks to Yihe Li’s proposal (2573R2), when we =delete a special member function or a function overload, we can specify a reason.

C++26: Delete with a Reason

by Sandor Dargo

From the article:

This is a practical and not very surprising change. Why do I say it’s not very surprising? Adding the ability to specify reasons for some operations has become a pattern in C++ evolution. Since C++11, we can add an optional message to static_assert, C++14 enriched the [[deprecated]] attribute with an optional reason, and the same happened in C++20 to the [[nodiscard]] attribute.

The reason is always similar, if not the same, to enhance maintainability and readability. When it comes to readability, not only the code but also the diagnostic messages become easier to grasp. Understanding why the compiler emitted a warning or an error becomes easier.

This latter is even more important than the readability of the codebase. I mean you could still add a comment right before or after a deleted function, but it wouldn’t be used in the compilers’ messages.

The usage is simple, if you want to specify a reason why a function or function overload is deleted, just pass a string literal containing the reason after delete surrounded by parentheses.

class NonCopyable
{
public:
    // ...
    NonCopyable() = default;

    // copy members
    NonCopyable(const NonCopyable&)
        = delete("Since this class manages unique resources, copy is not supported; use move instead.");
    NonCopyable& operator=(const NonCopyable&)
        = delete("Since this class manages unique resources, copy is not supported; use move instead.");
    
    // provide move members instead
    // ... 
};