From b26033d579a9df55f38f3b9ff8400c21f2a5717d Mon Sep 17 00:00:00 2001 From: =?utf8?q?Tomasz=20Kami=C5=84ski?= Date: Mon, 1 Sep 2025 16:11:05 +0200 Subject: [PATCH] libstdc++: Add stable names to C++98 implementation-defined docs. MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit Stable names are based on C++03 standard document, and some of then were changed since then. libstdc++-v3/ChangeLog: * doc/html/manual/status.html: Regenerated the file. * doc/xml/manual/status_cxx1998.xml: Add stable name to each entry. Reviewed-by: Jonathan Wakely Signed-off-by: Tomasz Kamiński --- libstdc++-v3/doc/html/manual/status.html | 103 +++++++++--------- .../doc/xml/manual/status_cxx1998.xml | 103 +++++++++--------- 2 files changed, 108 insertions(+), 98 deletions(-) diff --git a/libstdc++-v3/doc/html/manual/status.html b/libstdc++-v3/doc/html/manual/status.html index 5ca35217f66f..f3d4a229daf6 100644 --- a/libstdc++-v3/doc/html/manual/status.html +++ b/libstdc++-v3/doc/html/manual/status.html @@ -69,61 +69,65 @@ mainline GCC, not in any particular release. 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. + 1.9 [intro.execution]/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 + 17.4.4.5 [lib.reentrancy] Non-reentrant functions are + probably best discussed in the various sections on multithreading (see above). +

18.1 [lib.support.types]/4 The type of + NULL is described under + Support. +

18.3 [lib.support.start.term]/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 [lib.bad.alloc]/5 (bad_alloc), + 18.5.2 [lib.bad.cast]/5 (bad_cast), + 18.5.3 [lib.bad.typeid]/5 (bad_typeid), + 18.6.1 [lib.exception]/8 (exception), + 18.6.2.1 [lib.bad.exception]/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 +

18.5.1 [lib.type.info]/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, +

20.1.5 [lib.allocator.requirements]/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 [lib.char.traits.specializations.char]/3,4, + 21.1.3.2 [lib.char.traits.specializations.wchar.t]/2, + 21.3 [lib.basic.string]/6 basic_string::iterator, + basic_string::const_iterator, + 23.* [lib.containers]'s foo::iterator, + 27.* [lib.input.output]'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 +

21.1.3.1 [lib.char.traits.specializations.char]/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 +

22.* [lib.localization] 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 +

23.* [lib.containers] 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 +

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

27.4.2.4 [lib.ios.members.static/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 @@ -131,16 +135,17 @@ mainline GCC, not in any particular release. 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 +

27.6.1.1.2 [lib.istream::sentry], + 27.6.2.3 [lib.ostream::sentry] 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 [lib.stringbuf.virtuals]/16, + 27.8.1.4 [lib.filebuf.virtuals]/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. +

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

C++ 2011

This table is based on the table of contents of ISO/IEC diff --git a/libstdc++-v3/doc/xml/manual/status_cxx1998.xml b/libstdc++-v3/doc/xml/manual/status_cxx1998.xml index 6b84e7c36e25..3cabf742f77f 100644 --- a/libstdc++-v3/doc/xml/manual/status_cxx1998.xml +++ b/libstdc++-v3/doc/xml/manual/status_cxx1998.xml @@ -1063,77 +1063,81 @@ mainline GCC, not in any particular release. applicable. This list is probably incomplet and inkorrekt. - [1.9]/11 #3 If isatty(3) is true, then - interactive stream support is implied. + 1.9 [intro.execution]/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). + 17.4.4.5 [lib.reentrancy] 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.1 [lib.support.types]/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.3 [lib.support.start.term]/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 + 18.4.2.1 [lib.bad.alloc]/5 (bad_alloc), + 18.5.2 [lib.bad.cast]/5 (bad_cast), + 18.5.3 [lib.bad.typeid]/5 (bad_typeid), + 18.6.1 [lib.exception]/8 (exception), + 18.6.2.1 [lib.bad.exception]/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 + 18.5.1 [lib.type.info]/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. + 20.1.5 [lib.allocator.requirements]/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, + 21.1.3.1 [lib.char.traits.specializations.char]/3,4, + 21.1.3.2 [lib.char.traits.specializations.wchar.t]/2, + 21.3 [lib.basic.string]/6 basic_string::iterator, + basic_string::const_iterator, + 23.* [lib.containers]'s foo::iterator, + 27.* [lib.input.output]'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 + 21.1.3.1 [lib.char.traits.specializations.char]/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 + 22.* [lib.localization] 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 + 23.* [lib.containers] 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. + 26.2.8 [lib.complex.transcendentals/9 I have no + idea what complex<T>'s pow(0,0) returns. - [27.4.2.4]/2 Calling + 27.4.2.4 [lib.ios.members.static/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 @@ -1142,18 +1146,19 @@ mainline GCC, not in any particular release. 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.6.1.1.2 [lib.istream::sentry], + 27.6.2.3 [lib.ostream::sentry] 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 + 27.7.1.3 [lib.stringbuf.virtuals]/16, + 27.8.1.4 [lib.filebuf.virtuals]/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. + 27.8.1.4 [lib.filebuf.virtuals]/16 Calling + fstream::sync when a get area exists will... whatever + fflush() does, I think. -- 2.47.3