This status table is based on the table of contents of ISO/IEC 14882:2003.

This section describes the C++ support in the GCC 10 release series.

The ISO standard defines the following phrase:

We do so here, for the C++ library only. Behavior of the compiler, linker, runtime loader, and other elements of "the implementation" are documented elsewhere. Everything listed in Annex B, Implementation Qualities, are also part of the compiler, not the library.

For each entry, we give the section number of the standard, when applicable. This list is probably incomplet and inkorrekt.

[1.9]/11 #3 If isatty(3) is true, then interactive stream support is implied.

[17.4.4.5] Non-reentrant functions are probably best discussed in the various sections on multithreading (see above).

[18.1]/4 The type of NULL is described under Support.

[18.3]/8 Even though it's listed in the library sections, libstdc++ has zero control over what the cleanup code hands back to the runtime loader. Talk to the compiler people. :-)

[18.4.2.1]/5 (bad_alloc), [18.5.2]/5 (bad_cast), [18.5.3]/5 (bad_typeid), [18.6.1]/8 (exception), [18.6.2.1]/5 (bad_exception): The what() member function of class std::exception, and these other classes publicly derived from it, returns the name of the class, e.g. "std::bad_alloc".

[18.5.1]/7 The return value of std::type_info::name() is the mangled type name. You will need to call c++filt and pass the names as command-line parameters to demangle them, or call a runtime demangler function.

[20.1.5]/5 "Implementors are encouraged to supply libraries that can accept allocators that encapsulate more general memory models and that support non-equal instances. In such implementations, any requirements imposed on allocators by containers beyond those requirements that appear in Table 32, and the semantics of containers and algorithms when allocator instances compare non-equal, are implementation-defined." There is experimental support for non-equal allocators in the standard containers in C++98 mode. There are no additional requirements on allocators. It is undefined behaviour to swap two containers if their allocators are not equal.

[21.1.3.1]/3,4, [21.1.3.2]/2, [21.3]/6 basic_string::iterator, basic_string::const_iterator, [23.*]'s foo::iterator, [27.*]'s foo::*_type, others... Nope, these types are called implementation-defined because you shouldn't be taking advantage of their underlying types. Listing them here would defeat the purpose. :-)

[21.1.3.1]/5 I don't really know about the mbstate_t stuff... see the codecvt notes for what does exist.

[22.*] Anything and everything we have on locale implementation will be described under Localization.

[23.*] All of the containers in this clause define size_type as std::size_t and difference_type as std::ptrdiff_t.

[26.2.8]/9 I have no idea what complex<T>'s pow(0,0) returns.

[27.4.2.4]/2 Calling std::ios_base::sync_with_stdio after I/O has already been performed on the standard stream objects will flush the buffers, and destroy and recreate the underlying buffer instances. Whether or not the previously-written I/O is destroyed in this process depends mostly on the --enable-libio choice: for stdio, if the written data is already in the stdio buffer, the data may be completely safe!

[27.6.1.1.2], [27.6.2.3] The I/O sentry ctor and dtor can perform additional work than the minimum required. We are not currently taking advantage of this yet.

[27.7.1.3]/16, [27.8.1.4]/10 The effects of pubsetbuf/setbuf are described in the Input and Output chapter.

[27.8.1.4]/16 Calling fstream::sync when a get area exists will... whatever fflush() does, I think.

For behaviour which is also specified by the 1998 and 2003 standards, see C++ 1998/2003 Implementation Specific Behavior. This section only documents behaviour which is new in the 2011 standard.

17.6.5.12 [res.on.exception.handling] There are no implementation-defined exception classes, only standard exception classes (or classes derived from them) will be thrown.

17.6.5.14 [value.error.codes] The error_category for errors originating outside the OS, and the possible error code values for each error category, should be documented here.

18.6.2.2 [new.badlength] what() returns "std::bad_array_new_length".

20.6.9.1 [allocator.member]/5 Over-aligned types are not supported by std::allocator.

20.7.2.2.1 [util.smartptr.shared.const] When a shared_ptr constructor fails bad_alloc (or types derived from it) will be thrown, or when an allocator is passed to the constructor then any exceptions thrown by the allocator.

20.7.2.0 [util.smartptr.weakptr] what() returns "bad_weak_ptr".

20.8.9.1.3 [func.bind.place]/1 There are 29 placeholders defined and the placeholder types are CopyAssignable.

20.11.7.1 [time.clock.system]/3, /4 Time point values are truncated to time_t values. There is no loss of precision for conversions in the other direction.

20.15.7 [meta.trans]/2 aligned_storage does not support extended alignment.

21.2.3.2 [char.traits.specializations.char16_t], 21.2.3.3 [char.traits.specializations.char32_t] The types u16streampos and u32streampos are both synonyms for fpos<mbstate_t>. The function eof returns int_type(-1). char_traits<char16_t>::to_int_type will transform the "noncharacter" U+FFFF to U+FFFD (REPLACEMENT CHARACTER). This is done to ensure that to_int_type never returns the same value as eof, which is U+FFFF.

22.3.1 [locale] There is one global locale for the whole program, not per-thread.

22.4.5.1.2 [locale.time.get.virtuals], 22.4.5.3.2 [locale.time.put.virtuals] Additional supported formats should be documented here.

22.4.7.1.2 [locale.messages.virtuals] The mapping should be documented here.

23.3.2.1 [array.overview] array<T, N>::iterator is T* and array<T, N>::const_iterator is const T*.

23.5.4.2 [unord.map.cnstr], 23.5.5.2 [unord.multimap.cnstr], 23.5.6.2 [unord.set.cnstr], 23.5.7.2 [unord.multiset.cnstr] The default minimal bucket count is 0 for the default constructors, range constructors and initializer-list constructors.

25.3.12 [alg.random.shuffle] The two-argument overload of random_shuffle uses rand as the source of randomness.

26.5.5 [rand.predef] The type default_random_engine is a synonym for minstd_rand0.

26.5.6 [rand.device] The token parameter of the random_device constructor can be used to select a specific source of random bytes. The valid token values are shown in the list below. The default constructor uses the token "default".

An exception of type runtime_error will be thrown if a random_device object is constructed with an invalid token, or if it cannot open or read from the source of random bytes.

26.5.8.1 [rand.dist.general] The algorithms used by the distributions should be documented here.

26.8 [c.math] Whether the rand function introduces data races depends on the C library as the function is not provided by libstdc++.

27.8.2.1 [stringbuf.cons] Whether the sequence pointers are copied by the basic_stringbuf move constructor should be documented here.

27.9.1.2 [filebuf.cons] Whether the sequence pointers are copied by the basic_filebuf move constructor should be documented here.

28.5.1 [re.synopt], 28.5.2 [re.matchflag] , 28.5.3 [re.err] syntax_option_type, match_flag_type and error_type are unscoped enumeration types.

28.7 [re.traits] The blank character class corresponds to the ctype_base::blank mask.

29.4 [atomics.lockfree] The values of the ATOMIC_xxx_LOCK_FREE macros depend on the target and cannot be listed here.

30.2.3 [thread.req.native]/1 native_handle_type and native_handle are provided. The handle types are defined in terms of the Gthreads abstraction layer, although this is subject to change at any time. Any use of native_handle is inherently non-portable and not guaranteed to work between major releases of GCC.

30.6.1 [futures.overview]/2 launch is a scoped enumeration type with overloaded operators to support bitmask operations. There are no additional bitmask elements defined.

For behaviour which is also specified by previous standards, see C++ 1998/2003 Implementation Specific Behavior and C++ 2011 Implementation Specific Behavior. This section only documents behaviour which is new in the 2017 standard.

20.5.1.2 [headers] Whether names from Annex K are declared by C++ headers depends on whether the underlying C library supports Annex K and declares the names. For the GNU C library, there is no Annex K support and so none of its names are declared by C++ headers.

23.6.5 [optional.bad_optional_access] what() returns "bad optional access".

23.7.3 [variant.variant] variant supports over-aligned types.

23.7.10 [variant.bad.access] what() returns one of the strings "std::get: variant is valueless", "std::get: wrong index for variant", "std::visit: variant is valueless", or "std::visit<R>: variant is valueless".

23.12.5.2 [memory.resource.pool.options] Let S equal numeric_limits<size_t>::digits. The limit for maximum number of blocks in a chunk is given by 2^N-1, where N is min(19, 3 + S/2). The largest allocation size that will be allocated from a pool is 2²² when S > 20, otherwise 3072 when S > 16, otherwise 768.

23.12.6.1 [memory.resource.monotonic.buffer.ctor] The default next_buffer_size is 128 * sizeof(void*). The default growth factor is 1.5.

23.15.4.3 [meta.unary.prop] The predicate condition for has_unique_object_representations is true for all scalar types except floating point types.

23.19.3 [execpol.type], 28.4.3 [algorithms.parallel.exec] There are no implementation-defined execution policies.

24.4.2 [string.view.template] basic_string_view<C, T>::iterator is C* and basic_string_view<C, T>::const_iterator is const C*.

28.4.3 [algorithms.parallel.exec] Threads of execution created by std::thread provide concurrent forward progress guarantees, so threads of execution implicitly created by the library will provide parallel forward progress guarantees.

29.4.1 [cfenv.syn] The effects of the <cfenv> functions depends on whether the FENV_ACCESS pragma is supported, and on the C library that provides the header.

29.6.9 [c.math.rand] Whether the rand function may introduce data races depends on the target C library that provides the function.

29.9.5 [sf.cmath] The effect of calling the mathematical special functions with large inputs should be documented here.

30.10.2.1 [fs.conform.9945] The behavior of the filesystem library implementation will depend on the target operating system. Some features will not be supported on some targets. Symbolic links and file permissions are not supported on Windows.

30.10.5 [fs.filesystem.syn] The clock used for file times is an unspecified type with a signed 64-bit representation, capable of representing timestamps with nanosecond resolution. The clock's epoch is unspecified, but is not the same as the system clock's epoch.

30.10.7.1 [fs.path.generic] dot-dot in the root-directory refers to the root-directory itself. On Windows, a drive specifier such as "C:" or "z:" is treated as a root-name. On Cygwin, a path that begins with two successive directory separators is a root-name. Otherwise (for POSIX-like systems other than Cygwin), the implementation-defined root-name is an unspecified string which does not appear in any pathnames.

30.10.10.1 [fs.enum.path.format] The character sequence is always interpreted in the native pathname format.

30.10.15.4 [fs.op.file_size] If !is_regular_file(p), an error is reported.

30.10.15.32 [fs.op.rename] On Windows, filesystem::rename is implemented by calling MoveFileExW and so does not meet the requirements of POSIX rename when one or both of the paths resolves to an existing directory. Specifically, it is not possible to rename a directory to replace another directory (POSIX requires that to work if the directory being replaced is empty).