C++ 1998/2003
ISO C++
1998
Implementation Status
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.
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
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.