You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
MSVC STL supports C++20/23 without char8_t and C++14/17 with char8_t dialects (see #2748). As a result, availability of some components is controlled by feature-test macros rather than standard revisions.
However, there doesn't seem a general whether the predefined feature-test macro __cpp_char8_t or the library feature-test macro __cpp_lib_char8_t should be used for controlling, and both of them are currently used.
The rationale is that /Zc:char8_t is (perhaps surprisingly) available as an opt-in mode in C++14/17. In the STL, we enable minimal recognition of C++14/17 with char8_t by inspecting the compiler macro __cpp_char8_t. This is usually in always-available components that need to react to char8_t's presence, e.g. the type traits like is_integral_v:
char16_t, char32_t, short, unsigned short, int, unsigned int, long, unsigned long, long long, unsigned long long>;
However, we still don't want to enable C++20 library tech downlevel, so that's what __cpp_lib_char8_t guards. We would usually use plain _HAS_CXX20 guards, except that /Zc:char8_t- acts as an opt-out here. So that's why library tech like u8string_view is guarded this way:
MSVC STL supports C++20/23 without
char8_t
and C++14/17 withchar8_t
dialects (see #2748). As a result, availability of some components is controlled by feature-test macros rather than standard revisions.However, there doesn't seem a general whether the predefined feature-test macro
__cpp_char8_t
or the library feature-test macro__cpp_lib_char8_t
should be used for controlling, and both of them are currently used.STL/stl/inc/xstring
Lines 482 to 485 in c53ac59
STL/stl/inc/xstring
Lines 1789 to 1791 in c53ac59
Presumably we should consistently use one for controlling.
The text was updated successfully, but these errors were encountered: