Table of Contents
Last week the ISO committee met in Varna to discuss some of the first batch of C++26 features. It’s an excellent occasion to shed some light on the latest status and interesting C++ proposals.
By the way: This will be my first blog post with the #cpp26 tag!
Disclaimer: The views expressed in this article are my own and do not represent the opinion of the ISO C++ Committee.
Return to In-Person ISO Meetings
With the pandemic largely behind us, we’re left adapting to a blend of virtual and in-person meetings. The ISO Committee held its first “post-pandemic” in-person meeting in Kona, HI, USA, in November 2022, followed by another one in Issaquah, USA, in February 2023. These meetings predominantly follow a hybrid format.
Both meetings served to complete the work on C++23!
Check out the report from Herb Sutter’s winter update:
The Latest Varna Meeting
Last week, from June 12th to the 16th, a meeting took place in Varna, Bulgaria. If I recall correctly, this meeting was initially planned for June 2020 but was postponed due to the pandemic. Thankfully, it seems the committee is now back to its regular international meeting schedule.
Approximately 180 attendees participated this time, with two-thirds in person and one-third joining online.
This meeting was the first to focus entirely on the C++26 standard! A new batch of features has already been accepted. We’ll delve into the current status of this standard in the following section.
You can find more information about the meeting in Herb’s latest article:
And have a look at Think-Cell’s report: Trip report: Summer ISO C++ Meeting in Varna, Bulgaria | think-cell
The Status of C++23
Two ISO meetings - one in Kona in November and another in Issaquah in February - finalized the C++23 draft. The draft is ready and has been sent for final voting and editorial changes. We can anticipate the official ISO publication at the end of 2023.
See all of the C++23 features on the C++ Reference page:
The Status of C++26
In Varna, the committee approved the first 40 proposed change papers for C++26, encompassing everything from bug fixes to new features like hazard pointers and RCU.
The overall plan for C++26 can be found in P0592: To boldly suggest an overall plan for C++26
- C++26 prioritizes on-time delivery while focusing on key feature sets - the standard is rolled out using a “train model” of releases. There’s a set deadline (typically a year in advance) that features must meet to be included in the standard.
- High-priority items include Execution, further work on Ranges, and Reflection.
- Contracts and Pattern Matching are in progress, but their inclusion in C++26 isn’t guaranteed.
- Additional library support for Coroutines and Networking is also included.
As always, you can monitor their status on this comprehensive cppreference page:
Now, let’s explore some recent papers that caught my attention in H1
Here are the links for:
- 2023-05 Mailing Available : Standard C++
- 2023-04 Mailing Available : Standard C++
- 2023-02 Mailing Available : Standard C++
Let’s begin with a minor language feature:
P2169 “A Handy Placeholder with No Name”
P2169, voted into C++26
Occasionally, we are more interested in their side effects than their names for variables such as locks, scope guards, or parts of structured bindings. In these situations, we can use the single underscore
_, a convention in C and C++ for unused variables. It encapsulates the “I don’t care” sentiment that is suitable for placeholders.
[[maybe_unused]] auto [x, y, iDontCare] = f();
Can be re-written as:
auto [x, y, _] = f();
auto _ = foo(); // equivalent to
[[maybe_unused]] auto _ = f();
P2621 “UB? In My Lexer?”
P2621, voted into C++26
It appears that the following code:
int \\ // UB : universal character name across spliced lines
1 = 0;
// UB: unterminated string
const char * foo = "
Can generate UB in the Lexer! The paper proposes to address such holes, thereby ensuring a more robust compilation across different vendors.
P2530 “Hazard Pointers for C++26”
P2530, voted into C++26
A hazard pointer is a type of single-thread-owned pointer used to protect dynamic objects from premature reclamation during concurrent operations. The owning thread sets the pointer to an object, signaling that it’s not yet safe for reclamation. Removed objects are retired to the hazard pointer library, which assumes the reclamation responsibility. The basic principle is that an object can only be reclaimed once it’s confirmed that no hazard pointers have been pointing to it since before its retirement. The method revolves around the interaction between protection and deferred reclamation.
Here’s a quote by Andrei Alexandrescu and Maged Michael:
Each reader thread owns a single-writer/multi-reader shared pointer called “hazard pointer.” When a reader thread assigns the address of a map to its hazard pointer, it is basically announcing to other threads (writers), “I am reading this map. You can replace it if you want, but don’t change its contents and certainly keep your deleteing hands off it.”
- A hazard pointer safeguards dynamic objects during concurrent operations.
- Only the owning thread can set the pointer.
- Removed objects are retired to the hazard pointer library.
- An object can be reclaimed only after ensuring that no hazard pointers have been pointing to it since before its retirement.
- The method centers on the concept of protection and deferred reclamation.
The reference implementation of hazard pointers, which includes a superset of the proposed interface, is in the Folly open-source library.
voted into C++26
Update, thanks to comment from ben_craig : P0843
static_vector/inplace_vectorhasn’t been voted into C++26 yet. The overall design has been approved, but the specification in the paper hasn’t been approved
This paper proposes a revamped
boost::static_vector<T, Capacity> (see at boost), a dynamic yet compile-time capacity-fixed vector with embedded contiguous storage. The API is akin to
std::vector<T, A>, offering constant-time insertion/removal at the end and
O(size()) in other cases. The
static_vector is beneficial when memory allocation is unfeasible or detrimental to performance, or in scenarios where objects with complex lifetimes need static-memory segment allocation. This proposal suggests implementing
static_vector as a standalone type, with semantics and layout similar to
std::vector. The move semantics follow the
std::vector model, with
constexpr support provided for certain type conditions. Exception safety follows the same pattern as
std::vector. However, iterator invalidation guarantees differ slightly. The paper proposes a name change from
inplace_vector for clarity.
P1759 Native Handles and File Streams
P1759, voted into C++26
The C++ proposal introduces
native_handle_type as an alias to the file descriptor type used by a platform (e.g.,
int for POSIX,
HANDLE for Windows). It also adds a member function
.native_handle() to file stream classes (
basic_fstream) to return a
native_handle_type. The aim is to enhance the use of iostreams with OS-specific operations without having to reopen files.
auto nativeHandle = of.native_handle(); // New method
// Now you can perform platform-specific operations with nativeHandle
The proposal does not support constructing a file stream from a native handle nor getting a native handle from a
Over to You
What are your favorite proposals that could be included in the next C++ Standard?
Share your thoughts in the comments section below the article.
- Five Awesome C++ Papers for the Q2 2021 and C++23 Status
- Five Awesome C++ Papers for the Q1 2021 and C++23 Status
- Combining Collections with Zip in C++23 for Efficient Data Processing
- 5 Curious C++ Lambda Examples: Recursion, constexpr, Containers and More
- Ways to Refactor Toggle/Boolean Parameters in C++