Using a C++ container comes with a promise: the caller supplies a valid index. What if the library could also detect the moment that promise is broken?

On October 30, 2026, ISO C++ Blog highlighted Bartlomiej Filipek’s article on standard library hardening. Understanding this C++26 facility requires looking beyond the presence of a check to what happens when it fails.

For an existing codebase, two questions guide adoption: how does failure differ from an exception, and which standard library settings actually enable the checks? Vector indexing is a useful place to start.

Does hardened vector access throw an exception?

A std::vector<int> with three elements has valid indices 0, 1, and 2. Accessing v[3] is out of bounds, while v.at(3) throws std::out_of_range. These boundaries appear in the draft sequence container requirements.

C++26 hardening specifies runtime checks for selected preconditions. The current draft wording for hardened preconditions requires a hardened implementation to check them before other observable side effects of the function, using a terminating semantic. Violating the same conditions in a non-hardened implementation is undefined behavior.

Operation and configuration	Result of an out-of-bounds index
v.at(i)	Throws std::out_of_range
v[i] with the relevant hardening enabled	Detects a contract violation and terminates
v[i] in a non-hardened implementation	Undefined behavior

Wrapping hardened operator[] in try/catch does not provide the recovery path of at(). If users can submit invalid indices, validate them before access or design an exception-handling path. Expected input failures and broken programming assumptions need different handling.

An empty optional shows both the scope and the limits

Hardening extends beyond indexing. The operator* and operator-> operations on std::optional have a hardened precondition that a value is present. By contrast, value() throws std::bad_optional_access when empty. See the optional observer specification.

A missing username can be an ordinary application state. A has_value() branch or value_or() can handle that state deliberately. Hardening helps detect an unconditional access made under the mistaken assumption that a value exists.

The motivation is to add checks suitable for production without substantially rewriting existing calls. P3471R4, dated February 14, 2025, emphasizes low runtime overhead and explicitly excludes checking every precondition as a goal. It brings common requirements to an area previously covered by vendor-specific checks.

Enabling hardening therefore does not prove that a program is memory safe. Treat it as protection around selected library operations, alongside input validation and other ways of finding defects.

Enable checks through the standard library configuration

The next question is how the build enables those checks. The draft implementation requirements leave hardened status implementation-defined. Selecting a C++26 language mode alone does not establish whether checking is active.

Major libraries expose the following controls. These are entry points to implementation checks, not a guarantee of complete C++26 conformance.

Standard library	Explicit setting example
libstdc++	-D_GLIBCXX_ASSERTIONS
libc++	-D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_FAST
MSVC STL	/D_MSVC_STL_HARDENING=1

The libstdc++ macro documentation describes _GLIBCXX_ASSERTIONS as enabling extra precondition checks. Its current defaults enable assertions without optimization and disable them with optimization. Older versions can differ: a failure caught in a development build does not establish coverage in a release build.

The libc++ hardening documentation recommends FAST for most projects and reserves DEBUG for non-production use. User macros do not change the hardening of prebuilt library components, and defaults depend on the vendor.

The MSVC STL wiki documents both global and per-type controls. _ITERATOR_DEBUG_LEVEL raises separate ABI compatibility concerns between settings; it should not be treated as an interchangeable hardening switch.

Test failure behavior under production build conditions

Start by recording the standard library, its version, and its settings alongside the compiler. For example, the libc++ C++26 status page tracks library implementation separately from language support.

A useful validation approach is to run valid operations under production optimization settings, then exercise out-of-bounds access and empty optional dereferencing in isolated test processes. This is a proposed testing approach, not a report of measurements from a particular environment.

For a service, adoption also means deciding how to record abnormal termination and what unit of work to restart. Measure checking overhead on your workload, and use detected violations to revisit the assumptions at the call site.

Hardening adds places where an existing programming error can be detected and stopped. Handle recoverable input errors in the application, then add library checks for mistakes that escape those paths. That division of responsibility turns a build setting into a practical improvement.

Source

• Title: C++26: Standard Library Hardening Experiments -- Bartlomiej Filipek
• URL: https://isocpp.org//blog/2026/10/cpp26-standard-library-hardening-experiments-bartlomiej-filipek