Fact-checked by Grok 2 weeks ago

C++23

C++23, formally known as ISO/IEC 14882:2024, is the seventh edition of the international standard specifying requirements for implementations of the C++ programming language, a general-purpose language extending the ISO/IEC 9899:2018 C standard with object-oriented and generic programming facilities such as classes, templates, exceptions, namespaces, and operator overloading. Published by the International Organization for Standardization (ISO) in October 2024, it succeeds the C++20 standard (ISO/IEC 14882:2020) and incorporates technical corrections alongside new features designed to enhance code expressiveness, safety, performance, and modularity in areas like constant evaluation and error handling.

Core Language Enhancements

C++23 introduces several refinements to the language syntax and semantics to address modern programming needs. Notable additions include support for explicit object member functions (also known as "explicit this"), which allow non-static member functions to explicitly declare their object parameter for improved clarity in generic code and forwarding scenarios. The standard also adds multidimensional subscript operators, enabling operator[] to accept multiple arguments for more intuitive access to multi-dimensional data structures like arrays or matrices. Other key language features encompass new preprocessing directives #elifdef and #elifndef for conditional compilation based on macro definitions, the auto(x) decay-copying declaration for initializing variables with decayed types, and explicit lifetime extension mechanisms to prevent dangling references in temporary expressions. Additionally, C++23 improves support for better handling of international text and extends constexpr evaluation to more library functions, allowing compile-time computations in a broader range of contexts.

Standard Library Improvements

The C++23 standard library receives significant updates focused on usability and efficiency, including the introduction of standard library modules that export the core library contents (excluding macros) to facilitate faster compilation and better encapsulation in modular codebases. New types such as std::expected provide a standardized way to handle errors and optional results, similar to monadic patterns in other languages, while std::generator supports coroutine-based iteration for and asynchronous data production. Library enhancements also feature string formatting and printing facilities inspired by std::format from but expanded for more flexible output, new container and view types like std::mdspan for multi-dimensional arrays, and algorithms optimized for ranges. Further additions include the <spanstream> header for stream-like operations on spans and the std::stacktrace library for capturing and inspecting call stacks at runtime. These changes deliver targeted advancements in productivity and reliability for , , and high-performance applications. Compiler support for C++23 features is progressively rolling out in major implementations like , , and MSVC, with full conformance expected in subsequent releases.

Introduction

Overview

C++23 is the current ISO standard for , formally designated as ISO/IEC 14882:2024 and published in October 2024. The technical work on the standard was completed in February 2023 by the ISO/IEC JTC1/SC22/WG21 committee, marking the culmination of efforts to evolve the language while maintaining . This edition succeeds and represents a measured advancement in the language's . The primary goals of C++23 include enhancing executability through better integration of existing features, simplifying common programming patterns to improve developer productivity, and bolstering compile-time capabilities for more efficient . It also prioritizes the incorporation of prior Technical Specifications, such as modules and ranges, into the core standard to promote stability and avoid introducing highly experimental elements that could complicate adoption. In scope, C++23 offers a smaller yet more focused evolution compared to the transformative changes in C++20, with an emphasis on library enhancements for greater productivity and refinements to language precision for safer and more expressive code. Its impact on the C++ ecosystem includes enabling improved support for modern hardware via optimized data structures and multidimensional views, facilitating safer code through refined error handling, and diminishing dependence on traditional headers through mature support. These advancements collectively streamline workflows and enhance in contemporary applications.

Modern "Hello, World!" Example

A quintessential demonstration of C++23's advancements is the simplified "Hello, World!" program, which leverages the new and formatted output functions to eliminate traditional header inclusions and stream manipulations.
cpp
import std;

int main() {
    std::println("Hello, world!");
}
In this example, import std; brings in the entire as a , replacing the conventional #include directives and providing faster times with better encapsulation by avoiding from macros. Modules support for the standard library, including std, is detailed in the dedicated section on Modules and Import Support. Meanwhile, std::println from the <print> header outputs the formatted string to stdout followed by a , streamlining I/O operations that previously required std::cout, insertion operators, and explicit flushing via std::endl. To compile this program, a is required, such as 13 or later invoked with the -std=c++23 flag (e.g., g++ -std=c++23 hello.cpp -o hello), though full may vary by and could necessitate additional build configurations like for prebuilt standard modules. As of 2025, 15 or later offers full for modules and std::println. For comparison, the C++20 equivalent relies on headers and streams, resulting in more verbose code:
cpp
#include <iostream>

int main() {
    std::cout << "Hello, world!" << std::endl;
}
This contrast underscores C++23's emphasis on conciseness and modernity, reducing the program's length while maintaining equivalent functionality.

Standardization Process

Development Timeline

Following the finalization of C++20 at the WG21 meeting in Prague from February 10 to 15, 2020, the committee shifted focus to , adopting a development plan outlined in paper that emphasized completing foundational work on —initially introduced in C++20—and enhancing to improve library usability. The COVID-19 pandemic disrupted in-person gatherings, leading to the cancellation of the planned June 2020 meeting in Varna, Bulgaria, and a transition to virtual meetings throughout 2020 and 2021. During this period, key proposals advanced significantly, including explicit object parameters (P0849R8) for simplifying member function calls and std::expected (P0323R15) for error-handling utilities, both of which progressed toward adoption in C++23 through reflector discussions and virtual plenaries, such as the November 9, 2020, Zoom meeting. In 2022, the committee continued with virtual sessions early in the year, including the February virtual meeting, before resuming hybrid in-person formats with the November 7-12 meeting in Kona, Hawaii, hosted by the Standard C++ Foundation. This period approached feature freeze, achieved at the July 25 virtual plenary, where core features like coroutines library support (including ) and multidimensional arrays via were finalized for inclusion. The February 6-11, 2023, meeting in Issaquah, Washington, marked the completion of C++23's technical specifications, leading to the final committee draft N4950 dated May 10, 2023. Subsequent meetings in Varna, Bulgaria (June 12-17), and Kona, Hawaii (November 6-11), handled defect reports, wording refinements, and ballot preparations, leading to national body ratification. In 2024, the International Organization for Standardization (ISO) published C++23 as ISO/IEC 14882:2024 on October 1, formalizing the standard after editorial review. Post-publication, major compilers integrated C++23 support progressively; as of November 2025, GCC 15, Clang 19, and Visual Studio 2022 version 17.14 offer substantial to near-complete implementation, enabling widespread adoption.

Key Milestones and Meetings

The ISO/IEC JTC1/SC22/WG21 working group, known as the C++ standards committee, is responsible for evolving the C++ programming language standard through a collaborative process involving national body representatives and individual experts. This group reviews technical papers submitted by members, conducts discussions in working group sessions during triannual meetings, and uses polls to gauge consensus on proposed changes before forwarding recommendations for inclusion in the working draft. Key decisions shaping C++23 included several pivotal votes at WG21 meetings. At the February 2023 meeting in Issaquah, Washington, USA, the committee approved the final draft of the C++23 standard by unanimous consent after resolving all national body comments, marking the technical completion of the specification. Earlier, in June 2022 at the St. Louis meeting, WG21 polled in favor of including P2465R3, which introduced standard library modules such as std and std.compat to facilitate modular imports of the C++ library. However, the Contracts Technical Specification was rejected for integration into C++23 due to insufficient consensus stemming from concerns over semantic complexity and implementation challenges. C++23 incorporated features from several Technical Specifications (TS) into the core standard, promoting stability and adoption. The Library Fundamentals V3 TS contributed components like std::expected for error handling and std::mdspan for multidimensional array views. Enhancements from the Ranges TS, including additional views and algorithms, were fully integrated to extend C++20's ranges foundation. The Coroutines TS provided the basis for std::generator, enabling lazy sequence generation in standard library coroutines. These integrations were approved via polls in LEWG (Library Evolution Working Group) sessions leading up to the feature freeze in July 2022. Following the February 2023 feature freeze, WG21 addressed post-freeze defects through targeted resolutions. The Core Working Group (CWG) and Library Working Group (LWG) reviewed and fixed ambiguities in ranges, such as iterator invalidation rules, and attributes, including clarification of [[likely]] and [[unlikely]] semantics, via immediate-issue polls at the Issaquah meeting. WG21's evolution policy employs a decoupled model, where experimental features are first previewed in separate Technical Specifications to allow real-world testing and refinement without delaying the main standard's publication cycle. This approach enabled the progressive maturation of , , and library fundamentals from TS to full standardization in C++23.

Language Features

Core Syntax Enhancements

C++23 introduces core syntax enhancements that streamline member function definitions, operator overloads, literal expressions, and namespace declarations, thereby increasing code expressiveness while minimizing redundancy in common programming patterns. A key feature is deducing this (P0847R8), which permits non-static member functions to deduce their return type based on the cv- and ref-qualifiers of the implicit this parameter, eliminating the need for separate overloads to handle lvalue and rvalue contexts. This enables a unified implementation for operations like assignment or chaining, where the return type adjusts automatically—for instance, returning a reference for lvalues and an rvalue reference for rvalues. Consider this example in a class definition:
cpp
struct Widget {
    auto operator+=(const auto& rhs) { /* implementation */ return *this; }
};
Here, the deduced return type adapts seamlessly, fostering more concise fluent interfaces without sacrificing type safety. The explicit object parameter syntax, integral to the same proposal, further refines this by allowing this to be named as the first explicit parameter in member function signatures, treating the function akin to a free function for improved template forwarding and lambda integration. For example:
cpp
struct Foo {
    void print(this Foo& self) { /* use self */ }
};
This approach enhances generic programming by enabling perfect forwarding of the object parameter and simplifies capturing in lambdas, where explicit object handling aligns with non-member function patterns. The multidimensional subscript operator (P2128R6) extends operator[] to accept multiple arguments, supporting direct multi-index access for multidimensional data structures without relying on deprecated comma expressions or nested calls. This syntactic upgrade is particularly beneficial for user-defined types representing arrays or views, allowing overloads with fixed or variadic parameters that include the explicit object for consistency. An illustrative declaration is:
cpp
struct Matrix {
    double& operator[](this Matrix&& self, size_t row, size_t col);
};
Usage such as matrix[1, 2] = 3.14; becomes idiomatic, promoting readability in numerical and scientific computing while integrating with library features like multidimensional views. To mitigate common type promotion issues with size-related constants, C++23 adds literal suffixes for std::size_t and its signed counterpart (std::ptrdiff_t or equivalent), as specified in P0330R8. The 'uz' (or 'UZ') suffix denotes an unsigned size_t literal, while 'z' (or 'Z') indicates the signed variant, preventing implicit conversions and associated warnings. For instance:
cpp
std::vector<int> vec(42uz);
This precise typing ensures safer array sizing and indexing operations across platforms, where size_t may differ from built-in unsigned integers. C++23 also clarifies and reinforces support for nested inline namespaces within enclosing inline namespaces, enhancing library evolution through transitive visibility for versioned . Inline declarations propagate through nesting levels, allowing unqualified access to inner members as if declared in the outer scope, which simplifies maintaining backward-compatible hierarchies without altering lookup rules. This builds on foundations to facilitate cleaner, scalable namespace organization in large projects.

Compile-Time Improvements

C++23 introduces several enhancements to compile-time evaluation, enabling more sophisticated computations during compilation while maintaining efficiency. These improvements build on prior standards by expanding the scope of constant expressions, allowing developers to perform operations that were previously deferred to . Key advancements include conditional branching based on evaluation context, mechanisms for ensuring immediate evaluation in functions, and extended support for containers in constant expressions. One significant addition is the if consteval construct, which permits conditional compilation depending on whether a function is invoked in a constant evaluation context. This feature addresses limitations in distinguishing between compile-time and runtime invocations within constexpr and consteval functions, reducing reliance on the std::is_constant_evaluated() function and enabling more flexible code that behaves differently at compile time versus . For example, the following code snippet demonstrates its use:
cpp
consteval int compute(int x) {
    if consteval {
        return x * 2;  // Optimized for [compile-time](/page/Compile_time)
    } else {
        return x * 3;  // Fallback for [runtime](/page/Runtime)
    }
}
This allows for compile-time-only paths that might involve heavier computations, such as those simulating dynamic allocation, without affecting . To facilitate immediate functions—those required to evaluate at —C++23 introduces parenthesized auto(x) initialization. This syntax creates a prvalue from x as if it were passed by value to a , ensuring the expression is suitable for constant evaluation without odr-use () violations. It is particularly useful in expressions or definitions where guarantees are needed. Consider this example for a compile-time square :
cpp
constexpr auto square = [](auto(x)) { return x * x; };
static_assert(square(5) == 25);
This mechanism simplifies writing immediate functions by avoiding explicit casting or temporary materialization, promoting safer and more intuitive compile-time programming. C++23 builds on C++20's support for using standard library containers like std::vector and std::string in constant expressions under the transient allocation model, where any simulated dynamic allocation must be deallocated within the same constant evaluation. This enables temporary use of these containers for compile-time computations, such as generating data, but they cannot persist beyond the evaluation (persistent allocation is proposed for future standards). For instance, a constexpr function can use a vector internally to compute a value:
cpp
constexpr int fib(int n) {
    std::vector<int> v{0, 1};
    for (int i = 2; i < n; ++i) {
        v.push_back(v[i-1] + v[i-2]);
    }
    return v.back();
}
static_assert(fib(6) == 8);
This capability supports advanced metaprogramming, such as parsing or generating lookup tables at compile time, while adhering to the transient model to avoid actual runtime allocation. Similar support applies to std::string for compile-time string operations like concatenation. To enhance portability in internationalized code, C++23 mandates UTF-8 as the portable source file encoding, ensuring compilers accept UTF-8 input by default. This change standardizes handling of Unicode characters in source code, reducing encoding-related portability issues across platforms and compilers. It affects literal encoding and execution character sets, making it easier to write code with non-ASCII identifiers and strings without vendor-specific flags. Additionally, C++23 allows static operator[] as a member function, enabling array-like subscript access in constant expressions without requiring an object instance or triggering odr-use. This is valuable for stateless classes or constexpr contexts where traditional non-static operators would necessitate unnecessary object creation. For example:
cpp
struct ArrayView {
    static constexpr int operator[](size_t i) { return data[i]; }
    static constexpr int data[5] = {1, 2, 3, 4, 5};
};
static_assert(ArrayView::operator[](2) == 3);
This feature streamlines compile-time data access patterns, particularly in template metaprogramming, by treating the operator as a static utility without instance overhead.

Attribute and Diagnostic Features

C++23 introduces several attributes and diagnostic enhancements designed to provide programmers with finer control over compiler optimizations and improved error reporting during compilation. These features build on prior standards by standardizing optimization hints and refining how diagnostics are generated and displayed, particularly in template contexts. The [[assume]] attribute, for instance, enables developers to inform the compiler of assumed conditions without runtime evaluation, facilitating aggressive optimizations while introducing undefined behavior if the assumption proves false. Similarly, the [[likely]] and [[unlikely]] attributes, now applicable in broader contexts, offer branch prediction hints to guide code generation for performance-critical paths. The [[assume]] attribute allows a to assert that a given constant expression evaluates to true at a specific point in the code, enabling the compiler to optimize accordingly without verifying the condition at runtime. For example, consider the following code snippet where the assumption optimizes away unnecessary checks:
int process_positive(int x) {
    [[assume(x > 0)]];
    return x * 2;  // Compiler can assume x > 0, potentially simplifying operations
}
If execution reaches a point where the assumed expression is false, the behavior is undefined, placing the responsibility on the to ensure correctness. This feature standardizes compiler-specific extensions like MSVC's __assume and is particularly useful in performance-sensitive algorithms where guarantees certain invariants. Branch prediction hints are provided by the [[likely]] and [[unlikely]] attributes, which advise the on the expected frequency of paths to improve and utilization. These attributes can be applied to labels, statements, or if statements, with [[likely]] indicating a path that is anticipated to be taken most often and [[unlikely]] the opposite. An illustrative example is handling in a :
void handle_request(bool error) {
    if ([[unlikely]](error)) {
        // Rare error path: compiler may place this code out-of-line
        log_error();
        return;
    }
    // Common success path
    process_data();
}
By hinting at branch probabilities, these attributes help generate more efficient , especially in loops or conditionals with skewed distributions, though their impact depends on the compiler's implementation. Diagnostics in C++23 see enhancements through clarifications to static_assert, particularly in how messages are reported within instantiations and dependent contexts. Previously ambiguous behaviors in are now well-defined, allowing static_assert declarations to trigger diagnostics more reliably even when the assertion is conditionally evaluated. This includes support for attaching contextual notes to error messages, improving readability for complex errors. For instance:
template<typename T>
void check_type() {
    static_assert(sizeof(T) == 4, "T must be a 32-bit type");  // Now reliably emits in dependent contexts
}
Such improvements aid authors in providing informative compile-time feedback without relying on non-standard extensions. In response to feedback from national bodies during the standardization process, C++23 reverts the of compound assignment operators on volatile-qualified objects, restoring their original semantics for compatibility with systems and hardware-interfacing . This decision addresses concerns that the would break legacy in domains like device drivers, where volatile ensures memory operations are not optimized away. The affected operators, such as += and -= on volatile lvalues, now behave as before, performing a read-modify-write sequence atomically with respect to the . This reversion maintains support for low-level programming without introducing new behaviors.

Library Features

Modules and Import Support

C++23 advances the modules feature originally introduced in C++20 by standardizing support for the entire as a , enabling more efficient and encapsulated code organization without relying on traditional header inclusions. This integration resolves lingering issues from the earlier Modules Technical Specification, such as inconsistent behaviors and limited exposure, providing a production-ready mechanism for . Modules promote faster build times by compiling interface information once and reusing it, while reducing macro-related side effects and name collisions inherent in header files. A major addition in C++23 is the named module std, accessible via import std;, which exposes all declarations within namespace std from C++ standard headers (e.g., std::vector from <vector>) and C wrapper headers (e.g., std::fopen from <cstdio>), along with global operators like ::operator new from <new>. This design excludes global namespace equivalents to prevent namespace pollution, offering a clean import path for new code. For legacy compatibility, the std.compat module, imported as import std.compat;, includes everything from std plus the corresponding global namespace functions (e.g., ::fopen), easing the transition for codebases that rely on C-style globals. These modules are defined in the C++23 standard to balance adoption and modernity, with minimal impact on compilation throughput due to modular optimizations. Module partitions enhance scalability by allowing a single named module to be divided into a primary interface unit and multiple partition interface units, where partitions can be internal (non-exported) for private implementation or interface partitions for shared components. This structure supports better encapsulation in large projects by isolating details within partitions that are not visible outside the module. The global module fragment, delimited by module; before the module declaration, permits inclusions of headers (e.g., system headers like <windows.h>) that remain visible to importers without being exported, facilitating compatibility with non-modular code. Complementing this, the private module fragment—declared with module :private; and restricted to the primary module interface unit—hides internal declarations and definitions from importers, further strengthening encapsulation by preventing unintended exposure of implementation specifics. Header units in C++23 provide a bridge for existing headers, allowing them to be imported directly as import <header-name>; without full rewriting into module syntax. This treats the header's content as a self-contained unit, preserving macro definitions and inline functions while benefiting from module caching for repeated uses. C++23 refines header unit compatibility, improving integration with named and reducing parsing overhead in mixed header- environments. Export mechanisms in C++23 offer refined handling of within , permitting template declarations and definitions to be exported via the module without requiring full in every importing unit, unlike traditional headers where definitions must often be visible at the point of use. This enables more efficient template distribution, as the module's includes necessary template information for on demand, addressing prior limitations in the Modules TS.

Ranges and Algorithms

C++23 introduces several enhancements to the Ranges library, building on the foundation laid in C++20 by standardizing additional views and algorithms from the Ranges Technical Specification (TS) while adding new functionality to improve and expressiveness in . These changes emphasize , better support for heterogeneous data, and efficient reduction operations, enabling more idiomatic and performant code for iterating and transforming sequences without unnecessary copies. The updates follow the prioritization outlined in the C++23 Ranges plan, which categorizes features into tiers based on maturity and utility, ensuring that core views and algorithms are fully integrated into the . One key addition is the family of fold algorithms, which provide flexible ways to reduce a to a single value using a . The primary functions are std::ranges::fold_left and std::ranges::fold_right, which perform left-associative and right-associative folds, respectively, starting from an initial value. For example, std::ranges::fold_left applies the operation cumulatively from left to right, equivalent to the expression init op x1 op x2 op ... op xn, and is particularly useful for operations like summing or concatenating elements where order matters. These algorithms support both forwarding and input , with overloads that deduce the initial value from the first element if not provided, and they reside in <algorithm> to align with general-purpose reductions rather than numeric-specific ones. Additionally, std::ranges::fold_left_with_iter allows specifying a starting for partial folds, enhancing control over the reduction process. This design addresses limitations in prior standards, such as the lack of guaranteed left-to-right evaluation in std::reduce, and promotes safer, more predictable computations in parallel contexts when combined with execution policies in future standards. The std::views::join view is another significant enhancement, allowing the flattening of a nested range of ranges into a single flat sequence. It takes a view of ranges—such as a vector of vectors—and produces a concatenated view where inner ranges are seamlessly iterated as if they were a continuous sequence, preserving the input range's category (e.g., input or random access). For instance, applying views::join to a range of strings yields a single stream of characters, useful for text processing or aggregating subcollections without materialization. This view requires the outer range to model input_range and each inner range to model input_range as well, with support for prvalue non-views through relaxed constraints to avoid unnecessary temporaries. An extension, std::views::join_with, inserts a between joined elements, such as commas in CSV-like data, further aiding tasks. These features stem from efforts to make nested data handling more composable, directly addressing common patterns in functional-style programming. Improvements to the in C++23 enhance its utility for combining multiple heterogeneous into , supporting variadic numbers of input with better type deduction and integration. The std::views::zip adaptor produces a of tuple-like elements, where each holds the i-th element from each zipped , stopping at the shortest 's end to prevent out-of-bounds access. Unlike earlier experimental versions, the C++23 implementation uses std::tuple for more than two and std::pair for exactly two, ensuring compatibility with structured bindings and generic code; it also supports heterogeneous types by allowing arbitrary arguments without common type requirements. This enables scenarios like parallel over disparate containers, such as zipping a of keys with a of values for operations. The design includes optimizations for references in common like transform, making it efficient for lazy pipelines. New range-based algorithms expand search capabilities, including std::ranges::find_last and its variants (find_last_if, find_last_if_not), which locate the last occurrence of a value or -satisfying element in a . These return an to the found position or std::ranges::dangling if none exists, supporting bidirectional and random-access for efficiency. For example, std::ranges::find_last_if can identify the last even number in a sequence, complementing forward-only searches. Similarly, std::ranges::adjacent_find detects the first pair of consecutive elements satisfying a , rangified from the legacy version to work with views and return a subrange or pair for easier chaining. These additions fill gaps in backward and pairwise searching, promoting more expressive code without manual reverse iteration. C++23 fully standardizes several features from the Ranges TS, notably std::views::zip and std::views::enumerate, integrating them as views for immediate usability. The enumerate view pairs each element with its zero-based index in a , facilitating indexed operations like mapping with position awareness, and models the same category as its underlying view. This standardization ensures these adaptors are lightweight, composable, and free of the TS's experimental constraints, allowing seamless use in standard containers and algorithms.

Utilities and Formatting

C++23 introduces several enhancements to the standard library's utilities, focusing on improved error handling, formatted output, associative containers, and management. These additions aim to provide more robust, type-safe, and efficient tools for common programming tasks, building on prior standards while addressing longstanding needs in text processing and data organization. One key addition is std::print and std::println, which offer type-safe formatted output directly to like stdout or stderr, avoiding the overhead of intermediate construction required by std::format. These functions use a printf-like syntax with compile-time checks for format specifiers, ensuring arguments match the placeholders. For instance, the code std::print("Value: {:d}\n", 42); outputs "Value: 42" followed by a , while std::println automatically appends a . This design supports output portably and integrates with the <print> header, providing a convenient alternative to std::cout for simple and . To improve error handling, C++23 standardizes std::expected<T, E>, a monadic type that encapsulates either a successful value of type T or an error of type E, akin to optional results in other languages. It supports operations like value_or to retrieve the value with a default on error, and or_else for error recovery, promoting functional-style error propagation without exceptions. Constructors allow in-place construction of the value or error, and it integrates with for generic usage. For example, a might return std::expected<int, std::error_code>, enabling callers to handle or explicitly. This feature addresses the need for lightweight error handling in performance-critical code. Format string handling receives refinements through enhanced support in std::format, incorporating concepts for compile-time validation of user-defined formatters and better integration with standard types. Proposals extend formatting for ranges and tuples with customizable debug output. These changes leverage C++20's std::format foundation, adding specializations for library types like std::span and improving locale-aware formatting without altering core syntax. New associative containers std::flat_map and std::flat_set provide sorted, unique key-based storage using a contiguous underlying vector, offering faster iteration and smaller memory footprints compared to tree-based std::map and std::set for small-to-medium datasets. Elements are kept sorted by key, with insertion maintaining order via binary search, achieving O(log n) lookups and O(n log n) construction. Unlike traditional maps, they support reserving capacity to avoid reallocations, and provide views like keys() for key-only access. An example usage is std::flat_map<std::string, int> m; m.emplace("key", 42);, ideal for cache-friendly scenarios where iteration speed matters more than frequent insertions. Variants std::flat_multimap and std::flat_multiset allow duplicates. Time zone support in <chrono> is bolstered by std::chrono::zoned_time, which pairs a time_point with a time_zone for unambiguous local time representation, including automatic handling of ambiguities like daylight saving transitions. C++23 clarifies locale-dependent formatting for zoned times. This enables code like auto zt = zoned_time{current_zone(), sys_time{std::chrono::system_clock::now()}}; std::print("{:%F %T %Z}", zt); to output locale-aware dates with zone abbreviations, enhancing cross-platform date-time applications. Brief integration with ranges allows formatting sequences of times, as detailed elsewhere.

Multidimensional Arrays and Views

C++23 introduces std::mdspan, a non-owning multidimensional view that provides a multi-index over a contiguous sequence of objects in memory, enabling efficient representation of arrays with multiple without owning the underlying data. This class template is defined in the <mdspan> header and interprets the memory as a domain defined by extents in each , facilitating portable and performant access patterns in multidimensional data structures. The extents of an mdspan can be specified at compile time using std::extents, such as std::mdspan<int, std::extents<std::size_t, 3, 4>> view(arr);, which creates a view over a contiguous arr representing a 3-by-4 . Dynamic extents are supported through the std::dynamic_extent , allowing specification of sizes; for example, std::mdspan<float, std::dynamic_extent, std::dynamic_extent> dynamic_view(data, rows, cols); constructs a view with dimensions provided at . Extents can mix static and dynamic specifications, such as std::mdspan<float, 20, std::dynamic_extent> mixed_view(data, num_cols);, where the first dimension is fixed at 20 while the second varies. Layout policies in std::mdspan control the mapping of multidimensional indices to linear memory offsets, with std::layout_right providing row-major order (last index varies fastest, as in C-style arrays) and std::layout_left providing column-major order (first index varies fastest, as in Fortran). These policies are specified as template parameters, e.g., std::mdspan<int, std::extents<std::size_t, 3, 4>, std::layout_right> row_major_view(arr);, ensuring compatibility with diverse hardware and numerical libraries. Integration with C++23's multidimensional subscript operator allows intuitive access like view[i][j], where the language feature (detailed in Core Syntax Enhancements) enables operator[] to accept multiple arguments, returning nested views for subsequent indexing. This syntax supports zero or more arguments in operator[] overloads, aligning mdspan access with familiar array notations while preserving and efficiency. In (HPC) and scientific computing, std::mdspan addresses the need for lightweight, non-owning views over large datasets, avoiding the overhead of full array copies and enabling performance portability across accelerators and CPUs without vendor-specific extensions. It facilitates kernel algorithms in domains like linear algebra and simulations by providing a standard interface for multidimensional indexing, reducing boilerplate and improving interoperability with libraries such as those in the Kokkos ecosystem.

Other Library Additions

C++23 introduces the <stacktrace> header as part of the diagnostics library, providing facilities to capture, store, and output information at runtime. The core class std::stacktrace represents a sequence of stack frames, obtained via std::stacktrace::current() to capture the current or constructed from an exception object for error handling. Each frame is described by std::stacktrace_entry, which includes the source file name, function name, and , enabling detailed output through for streams like std::cout. To support in ranges using s—building on the syntax introduced in C++20—std::[generator](/page/Generator) is added to the . This class template generates a sequence of values on demand by suspending and resuming the returned from a function, integrating seamlessly with range-based algorithms via co_yield statements. For example, a can produce elements of type T or optionally std::optional<T> to signal completion, avoiding the need for custom types in common iterable scenarios. The <bit> header gains std::byteswap, a constexpr that reverses the byte order of an value, aiding conversions in protocols and without platform-specific code. It participates in overload resolution only for types and produces the same type as its argument, ensuring and compile-time evaluation where possible. Complementing this, std::ranges::views::as_rvalue (also known as std::views::as_rvalue) provides a range view adaptor that treats each element as an rvalue reference, equivalent to wrapping the range's iterators in std::move_iterator, to facilitate moving from containers in algorithms without explicit wrapping. For C compatibility and low-level string conversion, std::to_chars for integral types is made constexpr in C++23, enabling allocation-free, compile-time conversion of integers to character buffers in a specified base (, , or ). This update, per proposal P2291R3, ensures round-trip guarantees and locale independence, useful for embedded systems or performance-critical parsing without dynamic memory use.

Deprecations and Removals

Removed Language Features

In C++23, the ISO/IEC 14882 standard removed support for collection interfaces that had been part of the language since , as these features were never implemented in major implementations and provided limited practical value. Specifically, the functions std::declare_reachable, std::undeclare_reachable, std::declare_no_pointers, std::undeclare_no_pointers, and std::get_pointer_safety from the <gc> header were eliminated, along with the std::pointer_safety enumeration and the __STDCPP_STRICT_POINTER_SAFETY__ macro. Additionally, core language wording related to strict pointer , which aimed to support conservative collectors by guaranteeing pointer validity, was excised. This removal stemmed from the absence of any known or support for strict pointer over the past decade, with all major implementations defaulting to relaxed mode, rendering the feature obsolete and unhelpful for real-world collection in virtual machines or custom allocators. Another language cleanup in C++23 involved the elimination of non-encodable literals and multicharacter literals, which were previously allowed but led to inconsistent behavior across implementations due to varying execution set assumptions. Under the , attempts to form such literals, like L'non-encodable-char' where the character cannot be represented in the execution set, or L'abc' with multiple characters, now result in ill-formed code, requiring a diagnostic from the . This change simplifies the and reduces portability issues without impacting common use cases, as narrow literals or user-defined literals serve equivalent purposes. C++23 also removed support for concatenating mixed wide string literals, such as u"q" U"p", which previously allowed inconsistent combinations of encoding prefixes (e.g., u8, u, U, L). These are now ill-formed, promoting consistent encoding practices and aligning with enhanced Unicode support in the standard. This cleanup addresses ambiguities in literal formation without affecting typical string usage. These removals contribute to streamlining the C++ core language by excising unused or contradictory provisions accumulated from prior standards, particularly those in Annex D (compatibility) that no longer align with modern hardware and implementation realities. For instance, certain legacy rules conflicting with cache-coherent multiprocessor systems were pruned to focus the specification on practical, widely-adopted behaviors, thereby reducing complexity and specification bloat without breaking existing codebases. The overall rationale emphasizes enhancing maintainability and clarity for developers and implementers, prioritizing features with demonstrated utility over vestigial elements.

Deprecated Library Components

In C++23, the standard library deprecates several legacy components to promote safer, more efficient alternatives, continuing a process started in previous standards. The <codecvt> header, introduced in C++11 to support conversions between different character encodings via facets like std::codecvt_utf8, remains deprecated as established in C++17. This deprecation stems from the header's underspecification, absence of robust error handling, and potential security vulnerabilities in conversion operations. Although not removed in C++23, it is slated for elimination in C++26, with implementers advised to maintain in the interim. Developers are encouraged to migrate to third-party libraries such as ICU for comprehensive handling or leverage emerging standard facilities like std::text_encoding for basic encoding needs. C++23 newly deprecates std::aligned_storage and std::aligned_union from the <type_traits> header, which provided types for aligned storage allocation but are redundant with the more flexible std::align algorithm and modern alignment specifications introduced in C++11. These deprecations encourage use of aligned allocation functions and structured bindings for similar purposes, reducing reliance on utility classes that overlap with core language features. Additionally, the member std::numeric_limits::has_denorm is deprecated in C++23, as its behavior was underspecified for certain floating-point models and rarely used in practice. Developers should instead query support via std::numeric_limits::tininess_before or implementation-specific checks, aligning with updates to floating-point semantics in the standard. For migration from these deprecated components, C++23 emphasizes modern utilities like std::format for string and I/O operations that once relied on legacy encoding or shuffling patterns, offering type-safe and locale-aware formatting without the pitfalls of older facilities. Comprehensive tooling support in compilers flags these deprecations, facilitating gradual upgrades in large codebases.

Compiler and Tooling Support

Major Compiler Implementations

provides robust support for C++23, with core language features largely implemented starting in 14, released in May 2024. Substantial completion, including advanced modules and multidimensional array support via std::mdspan, arrived in 15.1 (April 2025), with further enhancements in 15.2 (August 2025). This version enhances experimental modules with built-in std and std.compat modules, alongside library additions like std::flat_map and std::flat_set. Clang, part of the LLVM project, began progressive implementation of C++23 features from Clang 13 in 2021, reaching substantial coverage by Clang 16 in 2023. Full support, enabling the -std=c++23 flag for comprehensive compliance, was achieved in 18, released in September 2024. This includes modules import syntax and standard library integrations, with ongoing refinements in subsequent point releases. Microsoft Visual C++ (MSVC) introduced C++23 support in 2022 version 17.10, released in May 2024, via the /std:c++23 compiler flag. By mid-2025, in version 17.14 (May 2025), key features such as modules and the <print> header with std::print and std::println became fully available, along with support for new lambda attributes, if consteval, and static operators, aligning with ISO conformance goals. Other compilers exhibit varying degrees of adoption. oneAPI DPC++/C++ Compiler version 2025.0, leveraging the 19 frontend, provides full C++23 support across host and device code. HPC SDK compilers, formerly PGI, offer complete C++23 compatibility in release 25.9 (September 2025), including GPU-accelerated elements. EDG-based frontends, used in tools like MSVC's IntelliSense, deliver partial C++23 implementation, covering core language but lagging on modules. To invoke C++23 mode, compilers typically require explicit flags: g++ -std=c++23 for GCC, clang++ -std=c++23 for Clang, and cl /std:c++23 for MSVC. These enable the standard's features while maintaining backward compatibility with prior modes.

Conformance Status

As of November 2025, major C++ compilers have achieved near-complete conformance to the C++23 core language features, with GCC 15.2, Clang 21, and MSVC in Visual Studio 2022 version 17.14 supporting approximately 95-100% of the standard's language requirements, though minor lags persist in niche areas such as nested inline namespaces and certain constexpr extensions. For instance, Clang 21 provides full implementation of core features like explicit object parameters (P0847R7) and if consteval (P1938R3), while MSVC 17.14 has completed support for declaration order layout (P1847R4) and removed garbage collection provisions (P2186R2). These advancements stem from ongoing efforts by the LLVM, GCC, and Microsoft teams to align with the ISO/IEC 14882:2024 standard finalized in 2023. Library conformance shows more variability, with the std module reaching about 95% implementation across vendors—fully supported in Clang's libc++ 21 for import std usage, enabling modular standard library access without traditional includes. The multidimensional array view std::mdspan is complete in all major libraries, including libstdc++ (GCC 15.2), libc++ (Clang 21), and MSVC STL, facilitating efficient multidimensional data handling in scientific computing. In contrast, the stacktrace library support varies by platform and implementation; it is fully available on with and but remains partial or platform-dependent on Windows with MSVC due to debugging API integrations. Known gaps include partial support for coroutine generators like std::generator in versions prior to MSVC 17.14 updates, where full resumption and yield mechanics are now stable, though core coroutines (P0912R5) are implemented since VS 2019. source file encoding (P2295R6), mandating portable support, is fully implemented across all major compilers, ensuring consistent handling in . Conformance is verified through ISO WG21 test suites and community-maintained resources like cppreference's compiler support tables, which track feature adoption via vendor reports and automated testing. Looking ahead, full C++23 conformance is anticipated across all major implementations by mid-2026, coinciding with early previews of C++26 features, as vendors prioritize ABI stability and library completeness in upcoming releases like 16 and 22.

References

  1. [1]
    ISO/IEC 14882:2024 - Programming languages — C++
    In stockISO/IEC 14882:2024 specifies requirements for C++ implementations, defining C++ and its facilities beyond C, such as classes and templates.
  2. [2]
    ISO/IEC 14882:2024—Programming languages - C++ - The ANSI Blog
    ISO/IEC 14882:2024 specifies requirements for C++ implementations, defining C++ as a general-purpose language based on ISO/IEC 9899.
  3. [3]
  4. [4]
    The Standard - Standard C++
    The current ISO C++ standard is C++23, formally known as ISO International Standard ISO/IEC 14882:2024(E) – Programming Language C++.
  5. [5]
    C++ Standards Support in GCC - GNU Project
    C++23 Support in GCC​​ GCC has experimental support for the latest revision of the C++ standard, which was finalized in 2023 and published in 2024.Missing: key | Show results with:key
  6. [6]
    C++23: The Next C++ Standard – MC++ BLOG - Modernes C++
    Jul 10, 2023 · C++23 will be the next C++ standard after C++20. This new standard significantly improves C++ but is less game-changing than C++98, C++11, or C++20.
  7. [7]
    To boldly suggest an overall plan for C++23 - Open Standards
    Nov 25, 2019 · Any C++23-era WG21 subgroup meeting works on no other NEW material until all possible progress on these items is exhausted first · Complete C++20.
  8. [8]
  9. [9]
    C++23: A Modularized Standard Library, std::print and std::println
    Aug 21, 2023 · In this post, I will write about the modularized standard library and the two convenience functions std::print and std::println . The new “Hello ...
  10. [10]
    C++20 approved, C++23 meetings and schedule update - Herb Sutter
    Sep 6, 2020 · This means that C++20 has now received final technical approval and is done with ISO balloting, and we expect it to be formally published ...
  11. [11]
    The Varna ISO C++ meeting is postponed - Sutter's Mill
    Mar 13, 2020 · Yesterday morning, I announced to the committee that the next ISO WG21 (C++) meeting originally planned for June 1-6 in Varna, Bulgaria, ...
  12. [12]
    Upcoming Meetings, Past Meetings - Standard C++
    Upcoming Meetings, Past Meetings. Upcoming face-to-face and virtual WG21 meetings. 2025-11-03 to 08: Kona, HI, USA; Standard C++ Foundation; 2026-03-23 to ...
  13. [13]
    [PDF] WG21 2022-02 Virtual Meeting Minutes of Meeting - Open Standards
    Feb 7, 2022 · WG21 2022-02 Virtual Meeting. Minutes of Meeting. ISO ... The meeting goals described above are derived from the schedule adopted in 2020 and.
  14. [14]
    INCITS C++/WG21 agenda: 7-12 November 2022, Kona, HI USA
    INCITS C++/WG21 Agenda: 7-12 November 2022, Kona, HI USA · Meeting notice and location: N4912 · Dates and times · Meeting objectives · Order of the meeting.
  15. [15]
    July 2022 ISO C++ committee virtual meeting report | The CLion Blog
    Jul 29, 2022 · The feature freeze doesn't mean that committee work on C++23 is now finished. We now have what's called a “committee draft” (CD), but there is ...
  16. [16]
    C++23 Feature Freeze: Summer ISO WG21 Meeting Results - Medium
    Aug 17, 2022 · I'll start with an overview of the meeting that took place in July. It proved to be a major breakthrough, resulting in a number of new features for the C++23 ...Missing: timeline | Show results with:timeline
  17. [17]
    [PDF] N4957 WG21 2023-06 Varna Minutes of Meeting.docx
    Jul 20, 2023 · Peter Brett : do we expect for iso to publish C++23 in 2023? Herb : maybe. Whatever date they put on it, it is C++23 in the marketplace. I ...
  18. [18]
    ISO/IEC JTC1/SC22/WG21 - The C++ Standards Committee - ISOCPP
    ISO/IEC JTC1/SC22/WG21 is the international standardization working group for the programming language C++.Papers · Mailings · Active Issues List · StandardsMissing: 2020 | Show results with:2020
  19. [19]
    The Committee - Standard C++
    WG21 was formed in 1990-91, and consists of accredited experts from member nations of ISO/IEC JTC1/SC22 who are interested in C++ work.
  20. [20]
    C++23 “Pandemic Edition” is complete (Trip report: Winter ISO C++ ...
    Feb 13, 2023 · C++23 “Pandemic Edition” is complete (Trip report: Winter ISO C++ standards meeting, Issaquah, WA, USA). Herb Sutter C++ 2023-02-13 2023-02-14 4 ...Missing: key | Show results with:key
  21. [21]
    [PDF] Standard Library Modules std and std.compat - Open Standards
    Mar 11, 2022 · This paper provides Standardese for two named modules: std and std.compat. import std; imports everything in namespace std from C++ headers ( ...
  22. [22]
    [PDF] C++26 Contract Assertions, Reasserted - Open Standards
    Oct 6, 2025 · After contract assertions were removed from the C++20 working draft in 2019 ([P1823R0]), WG21 formed SG21 with the mandate of designing a ...
  23. [23]
    C++ Extensions for Library Fundamentals, Version 3, Working Draft
    This technical specification describes extensions to the C++ Standard Library ( 2 ). ... C++ standards, WG21 (the ISO technical committee for the C++ ...Missing: 23 integrated Coroutines
  24. [24]
    A Plan for C++23 Ranges - Open Standards
    Oct 14, 2020 · This paper provides our opinion for how to categorize Ranges functionality into those three buckets. We go through, in turn: views-adjacent functionality, ...
  25. [25]
    [PDF] Contracts for C++
    Feb 29, 2024 · In this paper, we propose a Contracts facility for C++ that has been carefully considered by SG21 with the highest bar possible for consensus.
  26. [26]
    [PDF] N4943 WG21 2023-02 Issaquah Minutes of Meeting.docx
    Apr 2, 2023 · The meeting goal is to finalize NB comments and proceed with the publication of the C++23 standard. Agenda amendment - dates in the agenda are ...Missing: key milestones
  27. [27]
    [PDF] Multidimensional subscript operator - Open Standards
    Sep 14, 2021 · One syntax for multidimensional array access is the function call operator taking multiple indices, like this: a(x, y, z). In this example, a is ...
  28. [28]
    P0330R8: Literal Suffix for (signed) size_t - Open Standards
    Nov 24, 2019 · This paper proposes adding a zu s literal suffix that creates size_t literals, making the following warning-free.
  29. [29]
    `if consteval` - Open Standards
    Mar 22, 2021 · There are two problems this paper wishes to address. 3.1 Interaction between constexpr and consteval. The first problem is the interplay between ...
  30. [30]
    auto(x): decay-copy in the language - HackMD - Open Standards
    This paper proposes auto(x) and auto{x} for casting x into a prvalue as if passing x as a function argument by value.
  31. [31]
    More constexpr containers - Open Standards
    Transient constexpr allocations are dynamic memory allocations occurring during a constexpr evaluation that are deallocated before that evaluation completes.
  32. [32]
    [PDF] Support for UTF-8 as a portable source file encoding - Open Standards
    Jul 1, 2022 · We propose to mandate that C++ compilers must accept UTF-8 as an input format both to increase portability and to ensure that Unicode related ...
  33. [33]
  34. [34]
    A Plan for C++23 Ranges - Open Standards
    A Plan for C++23 Ranges. Document #:, P2214R2. Date: 2022-02-18 ... 2019-11-07. ranges compare algorithm are over-constrained. https://wg21.link/p1716r3.
  35. [35]
    ranges::fold - Open Standards
    Apr 22, 2022 · Lastly, the fold here is proposed to go into <algorithm> rather than <numeric> since there is nothing especially numeric about it. 3 Return Type.
  36. [36]
    join_view should join all views of ranges - Open Standards
    Mar 15, 2021 · 1 Abstract. This paper proposes relaxing the constraint on join_view to support joining ranges of prvalue non-view ranges.
  37. [37]
    views::join_with
    Jan 28, 2022 · views::join_with is an inverse of views::split. That is, given a range r and a pattern p, r | views::split(p) | views::join_with(p) should yield a range4 Wording · 4.2 Join_with · 24.7.? Join With View (range...
  38. [38]
    zip - Open Standards
    Jun 11, 2021 · 1 Abstract. This paper proposes. four views, zip , zip_transform , adjacent , and adjacent_transform ,; changes to tuple and pair necessary ...5.1 Tuple · 5.6 Zip · 24.7.? Zip View (range. Zip)
  39. [39]
    [PDF] find_last
    Jun 17, 2022 · Poll: We recommend making the change proposed in section 0.3 of P1223R3 for find_last, (making find_- last returning a subrange) for C++23.
  40. [40]
    [PDF] views::enumerate - Open Standards
    Dec 7, 2022 · The name views::enumerate denotes a range adaptor object. Given a subexpression E, the expression views::enumerate(E) is expression-equivalent ...
  41. [41]
    P0323R11: std::expected - WG21 Links
    Nov 16, 2021 · This proposal makes use of the "in-place" tag as defined in [C++17]. This proposal provides the same kind of "in-place" constructor that ...
  42. [42]
    MDSPAN - Open Standards
    Jul 13, 2022 · Our mdspan class template permits custom layouts. Our proposal comes with three memory layouts: layout_right : C or C++ style, row major, where ...
  43. [43]
    [PDF] mdspan in C++ - OSTI.gov
    This paper describes the design and implementation of mdspan, a proposed C++ standard multidimensional array view. (planned for inclusion in C++23). The ...
  44. [44]
    [PDF] Multidimensional subscript operator - Open Standards
    Feb 13, 2021 · Should we add a multidimentional operator to valarray? Again, we shouldn't change the meaning of existing code in C++23. We should only add.
  45. [45]
    Standard library header <stacktrace> (C++23) - cppreference.com
    May 1, 2024 · This header is part of the diagnostics library. Contents 1 Classes 1.1 Forward declarations 1.2 Type aliases 2 Functions 3 Synopsis 3.1 Class std::stacktrace_ ...
  46. [46]
    std::generator - cppreference.com
    Dec 9, 2024 · A std::generator generates a sequence of elements by repeatedly resuming the coroutine from which it was returned.
  47. [47]
    std::generator: Standard Library Coroutine Support - C++ Team Blog
    Feb 24, 2025 · std::generator is a C++23 feature that enables you to write concise, straightforward functions that generate sequences of values on-demand ...
  48. [48]
    std::byteswap - cppreference.com - C++ Reference
    Jan 2, 2025 · Reverses the bytes in the given integer value n. std::byteswap participates in overload resolution only if T satisfies integral, ie, T is an integer type.
  49. [49]
    std::move_iterator - cppreference.com
    Oct 30, 2024 · std::move_iterator is an iterator adaptor which behaves exactly like the underlying iterator (which must be at least a LegacyInputIterator or model input_ ...
  50. [50]
  51. [51]
  52. [52]
    [PDF] Add Constexpr Modifiers to Functions to_chars and from_chars for ...
    Sep 18, 2021 · The proposal is to add constexpr modifiers to `std::to_chars` and `std::from_chars` for integral types, as there is no standard way to do this ...<|control11|><|separator|>
  53. [53]
    P2186R2: Removing Garbage Collection Support
    ### Summary of P2186R2: Removal of Garbage Collection Support in C++23
  54. [54]
    [PDF] Remove non-encodable wide character literals and multicharacter ...
    Aug 27, 2021 · Non-encodable and multicharacter wide character literals are proposed to be ill-formed due to inconsistent interpretations and no benefit over ...
  55. [55]
    Reviewing Deprecated Facilities of C++20 for C++23
    This paper evaluates all the existing deprecated facilities in the C++20 standard, and recommends removing a subset from Annex D in C++23.
  56. [56]
    [PDF] Remove Deprecated Unicode Conversion Facets from C++26
    Nov 9, 2023 · The <codecvt> header was first provided by C++11 and then deprecated by C++17 due to its under- specification, notably a lack of error handling.
  57. [57]
    GCC 15 Release Series — Changes, New Features, and Fixes
    Oct 7, 2025 · Improved experimental support for C++23, including: std and std.compat modules (also supported for C++20). std::flat_map and std::flat_set ...Porting to GCC 15 · Statement Attributes · Sarif
  58. [58]
    Clang - C++ Programming Language Status - LLVM
    Remove non-encodable wide character literals and multicharacter wide character literals, P2362R3, Clang 14. Labels at the end of compound statements, P2324R2 ...
  59. [59]
    Microsoft C/C++ language conformance by Visual Studio version
    Expect these features under /std:c++20 after agreement is reached with WG21 that no further ABI-breaking changes are necessary. The remaining parts of <chrono> ...
  60. [60]
    What's New for C++ Developers in Visual Studio 2022 17.14
    May 15, 2025 · We've added support for several C++23 features, which are available under the /std:c++latest and /std:c++23preview flags. You can now omit ...
  61. [61]
    Intel® oneAPI DPC++/C++ Compiler Release Notes
    Intel® oneAPI DPC++/C++ Compiler version 2025.0 supports the C/C++ standards through the Clang 19 front end. Initiated support for C++2c, the next release of ...
  62. [62]
    HPC SDK Release Notes 25.9 documentation - NVIDIA Docs
    The HPC Compilers are compatible with gcc and g++ and use the GCC C and C++ libraries; the minimum compatible versions of GCC are listed in the table in Section ...
  63. [63]
    Supported C++ and C Language Features - Edison Design Group
    A list of C++23 features and their current implementation status can be found here. ... The list of C++11 features and the EDG releases can be retrieved by ...
  64. [64]
    libc++ C++23 Status
    In February 2023, the C++ standard committee approved this draft, and sent it to ISO for approval as C++23. This page shows the status of libc++.<|separator|>
  65. [65]
    Using the C++23 std Module with Clang 18 - 0xStubs
    With C++23, the standard library is now supposed to provide an std module that can be used instead of all the #include s that we are used to.
  66. [66]
    107761 – Implement C++23 <mdspan> - GNU
    Jul 8, 2025 · I've implemented c++23 features for <mdspan> in libstdc++ (hopefully) which is inspired by other reference implementations (libc++, STL, Kokkos).
  67. [67]
    Apple Clang 21 unable to compile with c++ 23 stacktrace header
    Sep 16, 2025 · Clang's C++ libraries (as of 21.1.1) do not yet support stacktrace , as indicated by the following. First, on the cppreference compiler ...Import std lib as modules with clang - c++ - Stack Overflowc++23 building with <stacktrace> library - Stack OverflowMore results from stackoverflow.comMissing: conformance mdspan
  68. [68]
    C++ 23 Standard - GeeksforGeeks
    Jul 23, 2025 · C++23, officially known as ISO/IEC 14882:2023, is the latest standardized version of the C++ programming language, published in 2023.
  69. [69]
    winspool/stdtests: C / C++ Compiler and standard library ... - GitHub
    Portable Testsuite to check a C / C++ Compiler and standard runtime libraries. Many compiler and the related standard libraries provide tests.
  70. [70]
  71. [71]
    Current Status - Standard C++
    Recent milestones: C++26 work in progress. C++23 and many TSes have been published, and work is now underway on more TSes and C++26 as shown below. click to ...<|separator|>