Asynchronous Programming with C++ - interview with the authors
Meeting C++ did an interview with the authors of "Asynchronous Programming with C++":
Asynchronous Programming with C++ - interview with the authors
by Jens Weller
Using Senders/Receivers -- Lucian Radu Teodorescu
C++26 will introduce senders/receivers. Lucian Radu Teodorescu demonstrates how to use them to write multithreaded code.
Using Senders/Receivers
by Lucian Radu Teodorescu
From the article:
This is a follow-up to the article in the previous issue of Overload, which introduced the upcoming C++26 senders/receivers framework [WG21Exec]. While the previous article focused on presenting the main concepts and outlining what will be standardized, this article demonstrates how to use the framework to build concurrent applications.
The goal is to showcase examples that are closer to real-world software rather than minimal examples. We address three problems that can benefit from multi-threaded execution: computing the Mandelbrot fractal, performing a concurrent sort, and applying a graphical transformation to a set of images.
All the code examples are available on GitHub [ExamplesCode]. We use stdexec [stdexec], the reference implementation for the senders/receivers proposal. Additionally, some features included in the examples are not yet accepted by the standard committee, though we hope they will be soon.
Towards safety & security in C++ - Daniela Engert - using std::cpp 205
In this keynote talk at using std::cpp 2025 Daniela Engert gives an overview of a possible path towards safety and security for future C++
Video: Towards safety & security in C++ -- by Daniela Engert -- using std::cpp 2025
How do I create an inserter iterator for unhinted insertion into std::map? -- Raymond Chen
The C++ standard library provides various inserters like back_inserter, front_inserter, and inserter, but for associative containers like std::map, only inserter is available, requiring a hint. However, if elements arrive in an unpredictable order, providing a hint could be inefficient, so a custom inserter that performs unhinted insertion can be a useful alternative.
How do I create an inserter iterator that does unhinted insertion into an associative container like
std::map?by Raymond Chen
From the article:
The C++ standard library contains various types of inserters:
back_inserter(c)which usesc.push_back(v).front_inserter(c)which usesc.push_front(v).inserter(c, it)which usesc.insert(it, v).C++ standard library associative containers do not have
push_backorpush_frontmethods; your only option is to use theinserter. But we also learned that the hinted insertion can speed up the operation if the hint is correct, or slow it down if the hint is wrong. (Or it might not have any effect at all.)What if you know that the items are arriving in an unpredictable order? You don’t want to provide a hint, because that’s a pessimization. The
inserterrequires you to pass a hint. What do you do if you don’t want to provide a hint?
C++26: Erroneous Behaviour -- Sandor Dargo
With C++26, the introduction of erroneous behavior provides a well-defined alternative to undefined behavior when reading uninitialized values, making it easier to diagnose and fix potential bugs. This blog post explores the impact of P2795R5, how compilers will handle erroneous values, and the new [[indeterminate]] attribute for cases where deliberate uninitialized values are needed.
C++26: Erroneous Behaviour
by Sandor Dargo
From the article:
If you pick a random talk at a C++ conference these days, there is a fair chance that the speaker will mention safety at least a couple of times. It’s probably fine like that. The committee and the community must think about improving both the safety situation and the reputation of C++.
If you follow what’s going on in this space, you are probably aware that people have different perspectives on safety. I think almost everybody finds it important, but they would solve the problem in their own way.
A big source of issues is certain manifestations of undefined behaviour. It affects both the safety and the stability of software. I remember that a few years ago when I was working on some services which had to support a 10x growth, one of the important points was to eliminate undefined behaviour as much as possible. One main point for us was to remove uninitialized variables which often lead to crashing services.
Thanks to P2795R5 by Thomas Köppe, uninitialized reads won’t be undefined behaviour anymore - starting from C++26. Instead, they will get a new behaviour called “erroneous behaviour”.
The great advantage of erroneous behaviour is that it will work just by recompiling existing code. It will diagnose where you forgot to initialize variables. You don’t have to systematically go through your code and let’s say declare everything as
autoto make sure that every variable has an initialized value. Which you probably wouldn’t do anyway.But what is this new behaviour that on C++ Reference is even listed on the page of undefined behaviour? It’s well-defined, yet incorrect behaviour that compilers are recommended to diagnose. Is recommended enough?! Well, with the growing focus on safety, you can rest assured that an implementation that wouldn’t diagnose erroneous behaviour would be soon out of the game.
Contracts for C++ Explained in 5 Minutes -- Timur Doumler
Contract assertions, introduced in proposal P2900 for C++26, provide a robust mechanism for runtime correctness checks, offering more flexibility and power than the traditional assert macro. This blog post will explore how contract assertions work, their various evaluation semantics, and how they can improve code reliability with preconditions, postconditions, and custom violation handlers.
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!As the name says, contract assertions are assertions — correctness checks that the programmer can add to their code to detect bugs at runtime. So they’re just like the existing
assertmacro, except they’re not macros (which fixes a bunch of problems) and they’re way more flexible and powerful!
contract_assert replaces assertOur replacement forassertis calledcontract_assert. Unlikeassert,contract_assertis a proper keyword, but it works in the same way:auto w = getWidget();contract_assert(w.isValid());// a contract assertionprocessWidget(w);The default behaviour is also the same: the assertion is checked, and if the check fails, the program prints a diagnostic message and terminates.
A Pattern for Obtaining a Single Value While Holding a Lock -- Raymond Chen
When working with a mutex-protected variable, you often need to read or modify its value while holding the lock, but then operate on the value outside the lock to minimize contention. While the traditional approach involves copying the value within a locked scope, using an immediately-invoked lambda or helper function can streamline this process, enabling efficient copy elision or move semantics to optimize performance.
A Pattern for Obtaining a Single Value While Holding a Lock
by Raymond Chen
From the article:
It is often the case that you have a mutex or other lockable object which protects access to a complex variable, and you want to read the variable’s value (possibly modifying it in the process) while holding the lock, but then operate on the value outside the lock.
The traditional way is to do something like this:
// Assume we have these member variables std::mutex m_mutex; Widget m_widget; // Get a copy of the widget Widget widget; { auto guard = std::lock_guard(m_mutex); widget = m_widget; } ⟦ use the variable "widget" ⟧This does suffer from the problem of running the
Widgetconstructor for an object that we’re going to overwrite anyway. The compiler will also have to deal with the possibility that thelock_constructor throws an exception, forcing the destruction of a freshly-constructedguard Widget.
C++ Memory Management - an Interview with Patrice Roy
Patrice Roy has written a book on C++ Memory Management for Packt, this is an interview about his book
C++ Memory Management - an interview with Patrice Roy
Fun with C++26 reflection - Keyword Arguments -- Che
In this blog post, we’ll explore implementing order-independent keyword arguments for C++ through use of C++26’s proposed reflection features. I stumbled upon this technique while experimenting with reflection a few days ago and thought it might be worthwhile to share, as it nicely showcases just how powerful the proposed reflection features are.
Fun with C++26 reflection - Keyword Arguments
by Che
From the article:
An example implementation of the technique presented in this blog post can be found on GitHub. It can be used with Bloomberg’s experimental P2996 clang fork. If you enjoy these shenanigans, feel free to leave a star.
Prior art
Named, labeled or keyword arguments have been proposed many times over the years, but as EWG issue 150 notes: all of these attempts have failed. Here is several past proposals on the topic:
Since none of these proposals were accepted, we have to be somewhat creative to get similar functionality in C++. Naturally, there are various approaches to this problem. Below is a short overview of what you can already do without reflection.
Designated initializers
Let’s start with the simplest way to achieve keyword argument-like syntax. C++20 introduced designated initializers for aggregate types, which gives us the initialization syntax
Point{.x=42, .y=7}.In a function call’s argument list the type can potentially be deduced, so we could write
foo({.x=2, .y=2}). While this requires extra curly braces and.-prefixes for every member name, syntactically this is almost what we want.
A Brief and Incomplete Comparison of Memory Corruption Detection Tools -- Raymond Chen
Memory diagnostic tools can be divided into runtime detection tools like Address Sanitizer (ASAN), Valgrind, and Application Verifier, and recording tools like rr and Time Travel Debugging (TTD). While runtime tools help catch memory errors as they occur, recording tools allow developers to trace memory modifications over time, making them a powerful combination for debugging complex issues.
A Brief and Incomplete Comparison of Memory Corruption Detection Tools
by Raymond Chen
From the article:
I promised last time to do a comparison of memory diagnostic tools. We have runtime diagnostic tools Address Sanitizer (ASAN), Valgrind, and Application Verifier (AppVerifier, avrf), and we have recording tools rr, and Time Travel Debugging (TTD)
First, the runtime tools:
ASAN detects a lot more types of memory errors, but it requires that you recompile everything. This can be limiting if you suspect that the problem is coming from a component you cannot recompile (say because you aren’t set up to recompile it, or because you don’t have the source code). Valgrind and AppVerifier have the advantage that you can turn them on for a process without requiring a recompilation. That means that you can ask a customer to turn it on at their site, without having to deliver a custom build to them. This is even more important on Windows because you have no chance of giving them an ASAN-enabled version of, say, kernel32.dll.
