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

This page describes the C++ support in mainline GCC SVN, not in any particular release.

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 here.

[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, simply returns the name of the class. But they are the mangled names; you will need to call c++filt and pass the names as command-line parameters to demangle them, or call a runtime demangler function. (The classes in <stdexcept> have constructors which require an argument to use later for what() calls, so the problem of what()'s value does not arise in most user-defined exceptions.)

[18.5.1]/7 The return value of std::type_info::name() is the mangled type name (see the previous entry for more).

[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." As yet we don't have any allocators which compare non-equal, so we can't describe how they behave.

[21.1.3.1]/3,4, [21.1.3.2]/2, [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 chapter 22 notes for what does exist.

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

[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 this chapter.

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