October 25, Pavia, Italy
November 6-8, Berlin, Germany
November 3-8, Kona, HI, USA
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.
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!
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!
By Blog Staff | Feb 7, 2025 03:16 PM | Tags: None
The C++20 standard introduced a specialization of std:: for shared pointers: std::. How does it work?
Inside STL: The atomic shared_ptr
by Raymond Chen
From the article:
Recall that a normal
shared_ptrconsists of two pointers: A stored pointer that theshared_ptrreturns when you callget()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_ptrhas 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.
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.
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
deletesurrounded 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 // ... };
By Blog Staff | Feb 3, 2025 02:58 PM | Tags: None
In this episode, you learn about a change in the standard that can give you more performance, thanks to the implicit move.
C++ Insights Episode 57: More performance thanks to more implicit moves in C++20 - Andreas Fertig
By Blog Staff | Feb 1, 2025 02:49 PM | Tags: None
The C++ proposal for indirect and polymorphic introduces two new class templates designed to simplify working with dynamically allocated types while retaining value semantics. This post dives into a curious case with polymorphic, exploring why std::default_initializable<polymorphic<T>> evaluates to true—even when polymorphic<T> can't actually be default-initialized in practice.
When a default-initializable type actually isn't
by Kaashif Hymabaccus
From the article:
I was looking at a proposal for adding value-semantic dynamically-allocated types to C++. You can find it here. This proposal adds two class templates,
indirectandpolymorphic.The primary use case for this is to make it easier to write correct composite classes. A motivating example can be found through existential types.
Suppose you want a type T which owns (ownership is key) some objects implementing some interfaces. You don't know what concrete types the sub-objects have, and you don't care. You're fine with dynamic dispatch, with the overhead that entails at runtime. You want value semantics, meaning (among other things) copying T copies the sub-objects too.
In Rust, this is expressible through
Box<dyn T>, which lets us own objects and perform dynamic dispatch with value semantics. This is whatpolymorphicwill allow in C++, allowing you to avoid hacking aroundunique_ptr. See the proposal above for more detailed motivation.
By Blog Staff | Feb 1, 2025 01:10 PM | Tags: None
Clang provides a few options to generate timing report. Among them, -ftime-report and -ftime-trace can be used to analyze the performance of Clang's internal passes. This post focuses on the traditional -ftime-report, which uses a line-based textual format.
Understanding and Improving Clang -ftime-report
by Fangrui Song
From the article:
The output consists of information about multiple timer groups. The last group spans the largest interval and encompasses timing data from other groups.
Up to Clang 19, the last group is called "Clang front-end time report". You would see something like the following.
The "Clang front-end timer" timer measured the time spent in clang::FrontendAction::Execute, which includes lexing, parsing, semantic analysis, LLVM IR generation, optimization, and machine code generation. However, "Code Generation Time" and "LLVM IR Generation Time" belonged to the default timer group "Miscellaneous Ungrouped Timers". This caused confusion for many users. For example, https://aras-p.info/blog/2019/01/12/Investigating-compile-times-and-Clang-ftime-report/ elaborates on the issues.
By Blog Staff | Jan 29, 2025 11:29 AM | Tags: None
C++26 will introduce a new concurrency feature called std::execution, or senders/receivers. Lucian Radu Teodorescu explains the idea and how to use these in detail.
Senders/Receivers: An Introduction
by Lucian Radu Teodorescu
From the article:
In June 2024, at the WG21 plenary held in St. Louis, the P2300R10:
std::executionpaper [P2300R10], also known as senders/receivers, was formally adopted for inclusion in C++ 26. The content of the paper quickly found its way into the working draft for the C++ standard [WG21]. You can find more about the highlights of the St. Louis meeting in Herb Sutter’s trip report [Sutter24].Senders/receivers represent one of the major additions to C++, as they provide an underlying model for expressing computations, adding support for concurrency, parallelism, and asynchrony. By using senders/receivers, one can write programs that heavily and efficiently exploit concurrency, all while maintaining thread safety (no deadlocks, race conditions, etc.). This is applicable not only to a few classes of concurrent problems but, at least in theory, to all types of concurrency problems. Senders/receivers provide a cost-free way of expressing computations that can run on different hardware with different constraints. They support creating computation chains that execute work on the CPU, GPU, and also enable non-blocking I/O.
Although the proposal has many advantages, there are still people who see the addition of this feature to the C++ standard at this point as a mistake. Some of the cited reasons are the complexity of the feature, compilation times, immaturity, and teachability. The last one caught my attention.
In this article, I plan to provide an introduction to senders/receivers as described in P2300 (and some related papers). The goal is not necessarily to showcase the many advantages of this model or delve into the details of complex topics. Rather, it is to offer a gentle introduction for those who have never read the paper or watched a talk on senders/receivers. We want the reader to understand the basic concepts of using senders/receivers without needing to grasp the intricate details of their implementation.
The hope is that, by the end of the article, the reader will be able to write some programs that use senders/receivers. The examples here are written as if the reader is coding with the feature already included in the standard library. Currently, no standard library provider ships senders/receivers; however, the reader can use the reference implementation of the feature [stdexec].
