New features in C++26

ISO releases new C++ language standards on a three-year cadence; now that it's been more than a year since the finalization of C++23, we have a good idea of what features could be adopted for C++26 — although proposals can still be submitted until January 2025. Of particular interest is the addition of support for hazard pointers and user-space read-copy-update (RCU). Even though C++26 is not yet a standard, many of the proposed features are already available to experiment with in GCC or Clang.

New threading libraries

Hazard pointers are a technique for building lock-free concurrent code. In a system with hazard pointers, each thread keeps a list of shared objects that it is currently accessing. Other threads can use that information to avoid modifying or freeing objects that are still in use.

In the proposed C++ library, a thread that wants to free a potentially shared object instead "retires" it, passing the responsibility for reclaiming the object to the library. Retiring an object is done atomically, such that there can be no new readers after an object is retired. When an object is retired, the library checks to see whether any existing hazard pointers reference it. If it is still referenced, it is added to a set of retired objects, which are rechecked periodically (when another object is retired, not on a timer). The object is freed once no hazard pointers reference it.

The proposed interface requires any classes protected by a hazard pointer to be a subclass of hazard_pointer_obj_base. Then, users can call make_hazard_pointer() to create a hazard pointer. Calling the protect() method of the returned hazard pointer protects the object with the pointer, and the thread can use the object normally. A thread that wants to retire an object calls object->retire(), which hands it over to the library. In all, the proposed API would be used like this:

    // Register a new (empty) hazard pointer with the library
    hazard_pointer hp = make_hazard_pointer();

    // Acquire a pointer to the object that needs protecting
    const atomic<T*>& object = ...;

    // Protect the pointer by putting it in the hazard_pointer
    T* normal_pointer = hp.protect(object);

    ... // Perform operations using normal_pointer

    // Remove the object from the hazard_pointer once done,
    // or let RAII clean up the hazard_pointer.
    hp.reset_protection(normal_pointer);

    // Meanwhile, another thread could call
    object->retire()

Hazard pointers aren't the only addition, however. User-space RCU support has also been proposed for inclusion. RCU is a technique that is widely used in the Linux kernel. Access to an object protected by RCU is done through a pointer; when a thread wants to change the object, it first makes a separate copy, and then edits that copy. Finally, the thread atomically swaps the pointer to point to the new copy. Using a compare-and-exchange instruction lets the thread know that it will need to try again if it happened to contend with another writer. The library also keeps track of some information to determine when all readers have finished with the old version of the object, allowing the writing thread to free it. The exact details can vary between implementations, so the proposed API doesn't mandate a particular approach to ensuring that readers are done.

Like the hazard-pointer proposal, the new RCU library defines a rcu_obj_base class that objects which will be protected by RCU can inherit from. Unlike with hazard pointers, this inheritance is not required; rcu_retire can be used on objects that are not descendants of that class.

Both libraries already have reference implementations available. There are several user-space RCU libraries cited, but both proposals list the Apache-2.0-licensed folly library as the primary reference implementation. If accepted, these features will become part of the C++ standard library.

Other library changes

There's also a good number of proposals for features to include in the standard library that are smaller or less significant. C++26 could see a debugging header that supplies a breakpoint() function, a linear algebra header that incorporates features from BLAS, and a text encoding header that lets users access the IANA Character Sets registry — the official list of character sets that can be used on the internet.

There's a long list of fixes and updates to other parts of the standard library, including changes to charconv functions, several updates to formatting and printing, stable sorting at compile time, changes to make more types usable as map keys, and several removals of deprecated items.

New core language changes

Also planned for the new standard are changes to the language itself. Some are relatively small changes; C++26 will probably contain a clarification of what it means for an attribute to be ignorable, and a change to the wording describing how to determine the length of an array when some of the initializers use the brace elision feature. There are also a handful of small fixes for string literals, such as defining previously undefined behavior during lexing (including specifying that unterminated string literals are ill-formed), specifying that characters that can't be encoded in the source file's encoding are not permitted in string literals, and clarifying when string literals should be evaluated by the compiler.

But most of the upcoming changes are a good deal more interesting. One proposal would turn some infinite loops into defined behavior. This is particularly important for the correctness of some low-level code that uses infinite loops intentionally as a way to halt a thread. Infinite loops had originally been made undefined behavior in order to allow optimizing compilers to assume that programs made forward progress; in general, determining whether a loop condition ever becomes false is equivalent to the halting problem. If the compiler is allowed to assume that a loop will eventually halt, it can use that information to make optimizations that are otherwise not possible.

C and C++ have slightly different requirements for how implementations must treat infinite loops, however. C has an explicit exception for loops with constant control expressions. So, since C11, these two loops have been meaningfully different:

    int cond = ...;

    while (cond) {
        // ...
    }

    while (true) {
        if (!cond)
            break;
        // ...
    }

The former loop can be assumed to eventually terminate, but the latter loop cannot. In contrast, C++11 allows the compiler to assume that both loops must eventually terminate. The proposal would change these rules so that "trivial" infinite loops — those with empty bodies — are not considered undefined behavior. This is different from what C specifies, but it would allow low-level code that actually intends to have a CPU spin in an empty loop.

Another change would allow casting from void* to other types in constexpr, which is C++'s mechanism for compile-time code execution. Over time, the language has slowly been expanding what is possible at compile time, mostly in the form of library changes to mark functions as constexpr. But there are still some fundamental restrictions around constexpr code, many of which deal with memory. Allowing constexpr code to use void pointers is another step toward loosening those restrictions.

That isn't the only compile-time improvement — there are proposals to have static_assert() take a user-supplied message, as well as adding messages to the = delete syntax (which allows the programmer to suppress the generation of methods that the compiler normally provides, such as copy constructors). Both of those changes could make it easier to communicate the reasoning behind compile-time checks and make writing maintainable code easier. There is also a proposal to make binding a returned glvalue to a temporary value ill-formed. A glvalue is any expression where its evaluation determines the identity of an object or function — a "generalized lvalue" that could have something assigned to it. In other words, code like this will no longer be accepted:

    const std::string_view& getString() {
        static std::string s;
        return s;
    }

If getString() had returned a std::string directly, it would be — and remains — valid. The problem comes because a std::string_view& is a non-owning reference to a std::string_view. When the value is returned, the underlying std::string_view is freed, and the reference becomes dangling. Languages like Rust solve this problem with an ownership system; C++26 would not go that far — it would still be possible to write a function that returns a dangling reference. But it would become a bit more difficult to do by mistake, since references to temporary values (such as the implicit conversion to std::string_view&) would be detected by the compiler.

Template improvements

C++26 also has a few improvements planned for the template system. In C++, when a template takes a parameter with a "..." before the name, the compiler creates a special structure holding multiple parameters called a "pack". A small proposal would allow the [] operator to index into a pack in a template. To distinguish this from a normal index operation, the proposal provides new syntax for accessing an element of a pack: name...[]. For example:

    template <typename... T>
    constexpr auto first_plus_last(T... values) -> T...[0] {
        return T...[0](values...[0] + values...[sizeof...(values)-1]);
    }

Packs can also be used in more places, with one change permitting them in the friend declaration of a class. This change is potentially useful because it permits programmers to use templates to implement the passkey idiom, a technique for exposing given methods only to particular classes.

The last proposed changes to the language itself to date include two changes to variable bindings: allowing attributes on structured bindings and allowing _ in a binding to discard a value. Finally, there is an obscure change to how compilers are required to initialize template parameters, and a change to braced initializers that makes them more efficient.

C++ may not be the first language people consider when thinking about evolving languages, but it still sees several important improvements in each edition. If no problems crop up, these changes will likely be accepted during the C++26 standardization meetings next year. In the meantime, there is still an open window to reflect on these changes and contribute additional suggestions.

[Thanks to Alison Chaiken for the suggestion to cover user-space RCU that led to this article.]