C++ 1998/2003ISO C++1998Implementation Status
This status table is based on the table of contents of ISO/IEC 14882:2003.
This page describes the C++ support in the GCC 6 series.
Implementation Specific Behavior
The ISO standard defines the following phrase:
[1.3.5] implementation-defined behavior
Behavior, for a well-formed program construct and correct data, that
depends on the implementation and that each implementation
shall document.
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, 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." 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,
[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.