______________________________________________________________________
17 Library introduction [lib.library]
______________________________________________________________________
1 This clause defines the contents of the Standard C++ library, how a
well-formed C++ program makes use of the library, and how a conforming
implementation may provide the entities in the library.
2 The Standard C++ library contains components for: language support,
predefined exceptions, strings, locales, bit sets, bit strings,
dynamic arrays, complex numbers, and iostreams. The language support
components are required by certain parts of the C++ language, such as
memory allocation (_expr.new_, _expr.delete_) and exception processing
(_except.intro_).
3 The strings and other containers provide commonly used data types not
directly defined in the C++ language. The predefined exceptions pro
vide support for uniform error reporting from the components in the
library. Complex numbers extend support for numeric processing. The
iostreams components are the primary mechanism for C++ program
input/output.
4 This library also makes available the facilities of the Standard C
library, suitably adjusted to ensure static type safety.
5 This subclause describes the scope (_lib.scope_), references
(_lib.references_), definitions (_lib.definitions_), and method of
description (_lib.description_) for the library. Subclauses
(_lib.requirements_) and (_lib.language.support_) through
(_lib.input.output_) specify the contents of the library, and library
requirements and constraints on both well-formed C++ programs and con
forming implementations.
17.1 Definitions [lib.definitions]
--Category: A logical collection of library entities. Subclauses
_lib.language.support_ through _lib.input.output_ each describe a
single category of entities within the library.
--Comparison function: An operator function (_over.oper_) for any of
the equality (_expr.eq_) or relational (_expr.rel_) operators.
--Component: A group of library entities directly related as members,
parameters, or return types. For example, the class wstring and the
non-member functions that operate on wide-character strings can be
considered the wstring component.
--Default behavior: A description of replacement function and handler
function semantics. Any specific behavior provided by the implemen
tation, within the scope of the required behavior.
--Handler function: A non-reserved function whose definition may be
provided by a C++ program. A C++ program may designate a handler
function at various points in its execution, by supplying a pointer
to the function when calling any of the library functions that
install handler functions (_lib.language.support_).
--Modifier function: A class member function (_class.mfct_), other
than constructors, assignment, or destructor, that alters the state
of an object of the class. The state of an object can be obtained
by using one or more observer functions
--Observer function: A class member function (_class.mfct_) accesses
the state of an object of the class, but does not alter that state.
Observer functions are specified as const member functions
(_class.this_).
--Replacement function: A non-reserved function whose definition is
provided by a C++ program. Only one definition for such a function
is in effect for the duration of the program's execution, as the
result of creating the program (_lex.phases_) and resolving the def
initions of all translation units (_basic.link_).
--Required behavior: A description of replacement function and handler
function semantics, applicable to both the behavior provided by the
implementation and the behavior that shall be provided by any func
tion definition in the program. If a function defined in a C++ pro
gram fails to meet the required behavior when it executes, the
behavior is undefined.
--Reserved function: A function, specified as part of the Standard C++
library, that must be defined by the implementation. If a C++ pro
gram provides a definition for any reserved function, the results
are undefined. Subclause _intro.defs_ defines additional terms used
elsewhere in this International Standard.
17.2 Method of description [lib.description]
1 This subclause describes the conventions used throughout clause
_lib.library_ to describe the Standard C++ library. It describes the
structures of the normative subclauses _lib.language.support_ through
_lib.input.output_ (_lib.structure_), conventions used to specify con
straints on template arguments(_lib.template.constraints_), conven
tions to describe types defined by an implementation
(_lib.implementation.types_), and other editorial conventions
(_lib.res.and.conventions_).
17.2.1 Structure of each subclause [lib.structure]
1 Subclause _lib.organization_ provides a summary of the Standard C++
library's contents. Other Library clauses provide detailed specifica
tions for each of the components in the library, as shown in Table 1:
Table 1--Library Categories
Clause Category
_lib.language.support_ Language support
_lib.diagnostics_ Diagnostics
_lib.utilities_ General utilities
_lib.strings_ Strings
_lib.localization_ Localization
_lib.containers_ Containers
_lib.iterators_ Iterators
_lib.algorithms_ Algorithms
_lib.numerics_ Numerics
_lib.input.output_ Input/output
2 Each Library clause contains the following elements:
--Summary
--Detailed specifications
--References to the Standard C library
3 The Summary provides a synopsis of the category, listing the headers
specified in the subclause and the library entities provided in each
header. The summary and the detailed specifications are presented in
the order:
--Macros
--Values
--Types
--Classes
--Functions
--Objects
4 The detailed specifications each contain the following elements:1)
_________________________
1) The form of these specifications was designed to follow the conven
--Name and brief description
--Synopsis (class definition or function prototype, as appropriate)
--Restrictions on template arguments, if any
--Decription of class invariants
--Description of function semantics
5 Descriptions of class member functions follow the order (as
appropriate):2)
--Constructor(s) and destructor
--Copying & assignment functions
--Comparison functions
--Modifier functions
--Observer functions
--Operators and other non-member functions
6 Descriptions of function semantics contain the following elements (as
appropriate):3)
--Requires, the preconditions for calling the function
--Effects, the actions performed by the function, and/or the postcon
ditions established by the function
--Returns, a description of the value(s) returned by the function
--Throws, any exceptions thrown by the function, and the conditions
that would cause the exception
7 For non-reserved replacement and handler functions, this clause speci
fies two behaviors for the functions in question: their required and
default behavior. The default behavior describes a function defini
tion provided by the implementation. The required behavior describes
the semantics of a function definition provided by either the imple
mentation or a C++ program. Where no distinction is explicitly made
in the description, the behavior described is the required behavior.
_________________________
tions established by existing C++ library vendors.
2) To save space, items that do not apply to a class are omitted. For
example, if a class does not specify any comparison functions, there
will be no ``Comparison functions'' subclause.
3) To save space, items that do not apply to a function are omitted.
For example, if a function does not specify any preconditions, there
will be no ``Requires'' paragraph.
17.2.2 Constraints on template [lib.template.constraints]
arguments
1 This subclause describes names that are used to specify constraints on
template arguments. These names are used, instead of the keyword
class, to describe the types that may be supplied as arguments by a
C++ program when instantiating template components from the library.
2 To ensure that the different components in a library work together,
they must satisfy some basic requirements. Requirements should be as
general as possible, so instead of saying ``class X has to define a
member function operator++(),'' we say ``for any object x of class X,
++x is defined.'' (It is unspecified whether the operator is a member
or a global function.) Requirements are stated in terms of well-
defined expressions, which define valid terms of the types that sat
isfy the requirements. For every set of requirements there is a table
that specifies an initial set of the valid expressions and their
semantics. Any generic algorithm that uses the requirements has to be
written in terms of the valid expressions for its formal type parame
ters.
3 If an operation is required to be linear time, it means no worse than
linear time, and a constant time operation satisfies the requirement.
4 In some cases we present the semantic requirements using C++ code.
Such code is intended as a specification of equivalence of a construct
to another construct, not necessarily as the way the construct must be
implemented (although in some cases the code given is unambiguously
the optimum implementation).
17.2.2.1 Traits [lib.trait.types]
1 The string and iostreams components use an explicit representation of
operations required of template arguments. They use a template class
name XXX_baggage to define these constraints.
+------- BEGIN BOX 1 -------+
At the Kitchener meeting, the Library WG decided to change the names
used from ``baggage'' to ``traits''. However, Tom Plum objected to
doing this without a formal proposal and vote. These names are there
fore unresolved, and subject to change.
+------- END BOX 1 -------+
17.2.2.2 Iterator types [lib.iterator.types]
1 Iterators are a generalization of pointers that allow a programmer to
work with different data structures (containers) in a uniform manner.
To be able to construct template algorithms that work correctly and
efficiently on different types of data structures, we need to formal
ize not just the interfaces but also the semantics and complexity
assumptions of iterators. Iterators are objects that have operator*
returning a value of some class or built-in type T called a value type
of the iterator. For every iterator type X for which equality is
defined, there is a corresponding signed integral type called the dis
tance type of the iterator.
2 Since iterators are a generalization of pointers, their semantics is a
generalization of the semantics of pointers in C++. This assures that
every template function that takes iterators works with regular point
ers. Depending on the operations defined on them, there are five cat
egories of iterators: input iterators, output iterators, forward iter
ators, bidirectional iterators and random access iterators, as shown
in Table 2.
Table 2--Relations among iterator categories
+----------------------------------------------------------+
|Random access -> Bidirectional -> Forward -> Input |
| -> Output |
+----------------------------------------------------------+
3 Forward iterators satisfy all the requirements of the input and output
iterators and can be used whenever either kind is specified. Bidirec
tional iterators satisfy all the requirements of the forward iterators
and can be used whenever a forward iterator is specified. Random
access iterators satisfy all the requirements of bidirectional itera
tors and can be used whenever a bidirectional iterator is specified.
There is an additional attribute that forward, bidirectional and ran
dom access iterators might have, that is, they can be mutable or con
stant depending on whether the result of the operator* behaves as a
reference or as a reference to a constant. Constant iterators do not
satisfy the requirements for output iterators.
4 Just as a regular pointer to an array guarantees that there is a
pointer value pointing past the last element of the array, so for any
iterator type there is an iterator value that points past the last
element of a corresponding container. These values are called past-
the-end values. Values of the iterator for which the operator* is
defined are called dereferenceable. The library never assumes that
past-the-end values are dereferenceable. Iterators might also have
singular values that are not associated with any container. For exam
ple, after the declaration of an uninitialized pointer x (as with int*
x;), x should always be assumed to have a singular value of a pointer.
Results of most expressions are undefined for singular values. The
only exception is an assignment of a non-singular value to an iterator
that holds a singular value. In this case the singular value is over
written the same way as any other value. Dereferenceable and past-
the-end values are always non-singular.
5 An iterator j is called reachable from an iterator i if there is a
finite sequence of applications of operator++ to i that makes i == j.
If j is reachable from i, they refer to the same container.
6 Most of the library's algorithmic templates that operate on data
structures have interfaces that use ranges. A range is a pair of
iterators that designate the beginning and end of the computation. A
range [i, i) is an empty range; in general, a range [i, j) refers to
the elements in the data structure starting with the one pointed to by
i and up to but not including the one pointed to by j. Range [i, j)
is valid if and only if j is reachable from i. The result of the
application of the algorithms in the library to invalid ranges is
undefined.
7 All the categories of iterators require only those functions that are
realizable for a given category in constant time (amortized). There
fore, requirement tables for the iterators do not have a complexity
column.
8 In the following sections, we assume: a and b are values of X, n is a
value of the distance type Distance, u, tmp, and m are identifiers, r
is a value of X&, t is a value of value type T.
17.2.2.2.1 Input iterators [lib.input.iterators]
1 A class or a built-in type X satisfies the requirements of an input
iterator for the value type T if the following expressions are valid,
as shown in Table 3:
Table 3--Input iterator requirements
+----------------------------------------------------------------------------------+
|expression return type operational assertion/note |
| semantics pre/post-condition |
+----------------------------------------------------------------------------------+
|X(a) a == X(a). |
| note: a destructor is assumed. |
+----------------------------------------------------------------------------------+
|X u(a); |
|X u = a; post: u == a. |
+----------------------------------------------------------------------------------+
|a == b convertible to bool == is an equivalence relation. |
+----------------------------------------------------------------------------------+
|a != b convertible to bool !(a == b) |
+----------------------------------------------------------------------------------+
|*a convertible to T pre: a is dereferenceable. |
| a == b implies *a == *b. |
+----------------------------------------------------------------------------------+
|++r X& pre: r is dereferenceable. |
| post: r is dereferenceable or |
| r is past-the-end. |
| &r == &++r. |
+----------------------------------------------------------------------------------+
|r++ X { X tmp = r; |
| ++r; |
| return tmp; |
| } |
+----------------------------------------------------------------------------------+
2 NOTE: For input iterators, a == b does not imply ++a == ++b. (Equal
ity does not guarantee the substitution property or referential trans
parency.) Algorithms on input iterators should never attempt to pass
through the same iterator twice. They should be single pass algo
rithms. Value type T is not required to be an lvalue type. These
algorithms can be used with istreams as the source of the input data
through the istream_iterator class.
17.2.2.2.2 Output iterators [lib.output.iterators]
1 A class or a built-in type X satisfies the requirements of an output
iterator if the following expressions are valid, as shown in Table 4:
Table 4--Output iterator requirements
+---------------------------------------------------------------------------------+
|expression return type operational assertion/note |
| semantics pre/post-condition |
+---------------------------------------------------------------------------------+
|X(a) a = t is equivalent to X(a) = |
| t. |
| note: a destructor is assumed. |
+---------------------------------------------------------------------------------+
|X u(a); |
|X u = a; |
+---------------------------------------------------------------------------------+
|*a = t result is not used pre: a is dereferenceable. |
+---------------------------------------------------------------------------------+
|++r X& pre: r is dereferenceable. |
| post: r is dereferenceable or |
| r is past-the-end. |
| &a == &++a. |
+---------------------------------------------------------------------------------+
|r++ X { X tmp = r; |
| ++r; |
| return tmp; |
| } |
+---------------------------------------------------------------------------------+
2 NOTE: The only valid use of an operator* is on the left side of the
assignment statement. Assignment through the same value of the itera
tor happens only once. Algorithms on output iterators should never
attempt to pass through the same iterator twice. They should be sin
gle pass algorithms. Equality and inequality might not be defined.
Algorithms that take output iterators can be used with ostreams as the
destination for placing data through the ostream_iterator class as
well as with insert iterators and insert pointers.
17.2.2.2.3 Forward iterators [lib.forward.iterators]
1 A class or a built-in type X satisfies the requirements of a forward
iterator if the following expressions are valid, as shown in Table 5:
Table 5--Forward iterator requirements
+-------------------------------------------------------------------------------------+
|expression return type operational assertion/note |
| semantics pre/post-condition |
+-------------------------------------------------------------------------------------+
|X u; note: u might have a singular |
| value. |
| note: a destructor is assumed. |
+-------------------------------------------------------------------------------------+
|X() note: X() might be singular. |
+-------------------------------------------------------------------------------------+
|X(a) a == X(a). |
+-------------------------------------------------------------------------------------+
|X u(a); X u; u = a; post: u == a. |
|X u = a; |
+-------------------------------------------------------------------------------------+
|a == b convertible to bool == is an equivalence relation. |
+-------------------------------------------------------------------------------------+
|a != b convertible to bool !(a == b) |
+-------------------------------------------------------------------------------------+
|r = a X& post: r == a. |
+-------------------------------------------------------------------------------------+
|*a convertible to T pre: a is dereferenceable. |
| a == b implies *a == *b. |
| If X is mutable, *a = t is valid. |
+-------------------------------------------------------------------------------------+
|++r X& pre: r is dereferenceable. |
| post: r is dereferenceable or r |
| is past-the-end. |
| r == s and r is dereferenceable |
| implies ++r == ++r. |
| &a == &++a. |
+-------------------------------------------------------------------------------------+
|r++ X { X tmp = r; |
| ++r; |
| return tmp; |
| } |
+-------------------------------------------------------------------------------------+
2 NOTE: The condition that a == b implies ++a == ++b (which is not true
for input and output iterators) and the removal of the restrictions on
the number of the assignments through the iterator (which applies to
output iterators) allows the use of multi-pass one-directional algo
rithms with forward iterators.
17.2.2.2.4 Bidirectional iterators [lib.bidirectional.iterators]
1 A class or a built-in type X satisfies the requirements of a bidirec
tional iterator if to the table that specifies forward iterators we
add the following lines, as shown in Table 6:
Table 6--Bidirectional iterator requirements (in addition to forward iterator)
+-----------------------------------------------------------------------+
|expression return type operational assertion/note |
| semantics pre/post-condition |
+-----------------------------------------------------------------------+
|--r X& pre: there exists s such |
| that r == ++s. |
| post: s is dereferenceable. |
| --(++r) == r. |
| --r == --r implies r == s. |
| &r == &--r. |
+-----------------------------------------------------------------------+
|r-- X { X tmp = r; |
| --r; |
| return tmp; |
| } |
+-----------------------------------------------------------------------+
2 NOTE: Bidirectional iterators allow algorithms to move iterators back
ward as well as forward.
17.2.2.2.5 Random access iterators [lib.random.access.iterators]
1 A class or a built-in type X satisfies the requirements of a random
access iterator if to the table that specifies bidirectional iterators
we add the following lines, as shown in Table 7:
Table 7--Random access iterator requirements (in addition to bidirectional iterator)
+------------------------------------------------------------------------------------+
|expression return type operational assertion/note |
| semantics pre/post-condition |
+------------------------------------------------------------------------------------+
|r += n X& { Distance m = |
| n; |
| if (m >= 0) |
| while (m--) |
| ++r; |
| else |
| while (m++) |
| --r; |
| return r; } |
+------------------------------------------------------------------------------------+
|a + n { X tmp = a; |
| X return tmp += a + n == n + a. |
| n; } |
|n + a |
+------------------------------------------------------------------------------------+
|r -= n X& return r += -n; |
+------------------------------------------------------------------------------------+
|a - n X { X tmp = a; |
| return tmp -= |
| n; } |
+------------------------------------------------------------------------------------+
|b - a Distance { X tmp = a; pre: there exists a value n of |
| Distance m = Distance such that a + n == b. |
| 0; b == a + (b - a). |
| while (tmp != |
| b) |
| ++tmp, ++m; |
| return m; } |
+------------------------------------------------------------------------------------+
|a[n] convertible to T *(a + n) |
+------------------------------------------------------------------------------------+
|a < b convertible to bool b - a > 0 < is a total ordering relation |
+------------------------------------------------------------------------------------+
|a > b convertible to bool b < a > is a total ordering relation |
| opposite to <. |
+------------------------------------------------------------------------------------+
|a >= b convertible to bool !(a < b) |
+------------------------------------------------------------------------------------+
|a <= b convertible to bool !(a > b) |
+------------------------------------------------------------------------------------+
17.2.2.3 Allocator types [lib.allocator.types]
1 One of the common problems in portability is to be able to encapsulate
the information about the memory model. This information includes the
knowledge of pointer types, the type of their difference, the type of
the size of objects in this memory model, as well as the memory allo
cation and deallocation primitives for it.
2 The library addresses this problem by providing a standard set of
requirements for allocators, which are objects that encapsulate this
information. All of the containers are parameterized in terms of
allocators. That dramatically simplifies the task of dealing with
multiple memory models.
3 In the following Table 8, we assume X is an allocator class for
objects of type T, a is a value of X, n is of type X::size_type, p is
of type X::pointer which was obtained from X.
4 All the operations on the allocators are expected to be amortized con
stant time.
Table 8--Allocator requirements
--------------------------------------------------------------------------------
expression return type assertion/note
pre/post-condition
--------------------------------------------------------------------------------
X::value_type T
--------------------------------------------------------------------------------
X::pointer pointer to T the result of operator* of
values of X::pointer is of
value_type.
--------------------------------------------------------------------------------
X::const_pointer pointer to const T type the result of operator* of
values of X::const_pointer is
of const value_type; it is the
same type of pointer as
X::pointer, in particular,
sizeof(X::const_pointer) ==
sizeof(X::pointer).
--------------------------------------------------------------------------------
X::size_type unsigned integral type the type that can represent
the size of the largest object
in the memory model.
--------------------------------------------------------------------------------
X::difference_type signed integral type the type that can represent
the difference between any two
pointers in the memory model.
--------------------------------------------------------------------------------
X a; note: a destructor is assumed.
--------------------------------------------------------------------------------
a.allocate(n) X::pointer memory is allocated for n ob
jects of type T but objects
are not constructed. allocate
may raise an appropriate ex
ception.
--------------------------------------------------------------------------------
a.deallocate(p) result is not used all the objects in the area
pointed by p should be de
stroyed prior to the call of
the deallocate.
--------------------------------------------------------------------------------
a.init_page_size() X::size_type the returned value is the op
timal value for an initial
buffer size of the given type.
It is assumed that if k is re
turned by init_page_size, t is
the construction time for T,
and u is the time that it
takes to do allocate(k), then
k * t is much greater than u.
| |
| |
| |
| |
+------------------------------------------------------------------------------+
|a.max_size() X::size_type the size of the largest buffer |
| that can be allocated |
+------------------------------------------------------------------------------+
17.2.2.4 Container types [lib.container.types]
1 Containers are objects that store other objects. They control alloca
tion and deallocation of these objects through constructors, destruc
tors, insert and erase operations.
2 In the following Table 9, we assume X is a container class containing
objects of type T, a and b are values of X, u is an identifier and r
is a value of X&.
Table 9--Container requirements
---------------------------------------------------------------------------------------------------
expression return type assertion/note complexity
pre/post-condition
---------------------------------------------------------------------------------------------------
X::value_type T compile time
---------------------------------------------------------------------------------------------------
X::iterator iterator type pointing to T any iterator category except compile time
output iterator.
---------------------------------------------------------------------------------------------------
X::const_ iterator iterator type pointing to any iterator category except compile time
const T output iterator.
---------------------------------------------------------------------------------------------------
X::difference_type signed integral type is identical to the distance compile time
type of X::iterator and
X::const_iterator
---------------------------------------------------------------------------------------------------
X:: size_type unsigned integral type size_type can represent any compile time
non-negative value of differ
ence_type
---------------------------------------------------------------------------------------------------
X u; post: u.size() == 0. constant
---------------------------------------------------------------------------------------------------
X() X().size() == 0. constant
---------------------------------------------------------------------------------------------------
X(a) a == X(a). linear
---------------------------------------------------------------------------------------------------
X u(a); post: u == a. linear
X u = a; Equivalent to: X u; u = a;
---------------------------------------------------------------------------------------------------
(&a)-> result is not used post: a.size() == 0. linear
~X() note: the destructor is ap
plied to every element of a,
all the memory is returned.
---------------------------------------------------------------------------------------------------
a.begin() iterator; constant
const_iterator
for constant a
---------------------------------------------------------------------------------------------------
a.end() iterator; constant
const_iterator
for constant a
---------------------------------------------------------------------------------------------------
a == b convertible to bool == is an equivalence relation. linear
a.size()==b.size()
&& equal(a.begin(),
a.end(), b.begin())
---------------------------------------------------------------------------------------------------
| |
| |
| |
| |
|a != b convertible to bool Equivalent to: !(a == b) linear |
+-------------------------------------------------------------------------------------------------+
+---------------------------------------------------------------------------------+
|expression return type operational assertion/note complexity |
| semantics pre/post-condition |
+---------------------------------------------------------------------------------+
|r = a X& if (&r != &a) { post: r == a. linear |
| (&r)->X::~X(); |
| new (&r) X(a); |
| return r; } |
+---------------------------------------------------------------------------------+
|a.size() size_type a.end() - a.begin() constant |
+---------------------------------------------------------------------------------+
|a.max_ size_type size() of the constant |
| largest possible |
| container. |
|size() |
+---------------------------------------------------------------------------------+
|a.empty() convertible to bool a.size() == 0 constant |
+---------------------------------------------------------------------------------+
|a < b convertible to bool lexicographical_ pre: < is defined linear |
| compare (a.begin(), for values of T. |
| a.end(), < is a total or |
| b.begin(), dering relation. |
| b.end()) |
+---------------------------------------------------------------------------------+
|a > b convertible to bool b < a linear |
+---------------------------------------------------------------------------------+
|a <= b convertible to bool !(a > b) linear |
+---------------------------------------------------------------------------------+
|a >= b convertible to bool !(a < b) linear |
+---------------------------------------------------------------------------------+
Notes:
equal and lexicographical_compare are defined in Clause
(_lib.algorithms_).
3 The member function size() returns the number of elements in the con
tainer. Its semantics is defined by the rules of constructors,
inserts, and erases.
4 begin() returns an iterator referring to the first element in the con
tainer. end() returns an iterator which is the past-the-end value.
17.2.2.4.1 Sequences [lib.sequence.reqmts]
1 A sequence is a kind of container that organizes a finite set of
objects, all of the same type, into a strictly linear arrangement.
The library provides three basic kinds of sequence containers: vector,
list, and deque. It also provides container adaptors that make it
easy to construct abstract data types, such as stacks or queues, out
of the basic sequence kinds (or out of other kinds of sequences that
the user might define).
2 In the following Table 10, X is a sequence class, a is value of X, i
and j satisfy input iterator requirements, [i, j) is a valid range, n
is a value of X::size_type, p is a valid iterator to a, q, q1, q2 are
valid dereferenceable iterators to a, [q1, q2) is a valid range, t is
a value of X::value_type.
3 The complexities of the expressions are sequence dependent.
Table 10--Sequence requirements (in addition to container)
+----------------------------------------------------------------------------------------------+
| expression return type assertion/note |
| pre/post-condition |
+----------------------------------------------------------------------------------------------+
|X(n, t) post: size() == n. |
|X a(n, t); constructs a sequence with n copies of t. |
+----------------------------------------------------------------------------------------------+
|X(i, j) post: size() == distance between i and j. |
|X a(i, j); constructs a sequence equal to the range [i, j). |
+----------------------------------------------------------------------------------------------+
|a.insert(p, t) iterator inserts a copy of t before p. |
+----------------------------------------------------------------------------------------------+
|a.insert(p, n, t) result is not used inserts n copies of t before p. |
+----------------------------------------------------------------------------------------------+
|a.insert(p, i, j) result is not used inserts copies of elements in [i, j) before p. |
+----------------------------------------------------------------------------------------------+
|a.erase(q) result is not used erases the element pointed to by q. |
+----------------------------------------------------------------------------------------------+
|a.erase(q1, q2) result is not used erases the elements in the range [q1, q2). |
+----------------------------------------------------------------------------------------------+
4 vector, list, and deque offer the programmer different complexity
trade-offs and should be used accordingly. vector is the type of
sequence that should be used by default. list should be used when
there are frequent insertions and deletions from the middle of the
sequence. deque is the data structure of choice when most insertions
and deletions take place at the beginning or at the end of the
sequence.
5 iterator and const_iterator types for sequences have to be at least of
the forward iterator category.
6 Table 11:
Table 11--Optional sequence operations
+-----------------------------------------------------------------------+
| expression return type operational container |
| semantics |
+-----------------------------------------------------------------------+
|a.front() T&; const T& *a.begin() vector, list, |
| for constant a deque |
+-----------------------------------------------------------------------+
|a.back() T&; const T& *a.end() vector, list, |
| for constant a deque |
+-----------------------------------------------------------------------+
|a.push_front(x) void a.insert(a.begin(),x) list, deque |
+-----------------------------------------------------------------------+
|a.push_back(x) void a.insert(a.end(),x) vector, list, |
| deque |
+-----------------------------------------------------------------------+
|a.pop_front() void a.erase(a.begin()) list, deque |
+-----------------------------------------------------------------------+
|a.pop_back() void a.erase(--a.end()) vector, list, |
| deque |
+-----------------------------------------------------------------------+
|a[n] T&; const T& *(a.begin() + n) vector, deque |
| for constant a |
+-----------------------------------------------------------------------+
7 All the operations in the above table are provided only for the con
tainers for which they take constant time.
17.2.2.4.2 Associative containers [lib.associative.containers]
1 Associative containers provide an ability for fast retrieval of data
based on keys. The library provides four basic kinds of associative
containers: set, multiset, map and multimap.
2 All of them are parameterized on Key and an ordering relation Compare
that induces a total ordering on elements of Key. In addition, map
and multimap associate an arbitrary type T with the Key. The object
of type Compare is called the comparison object of a container.
3 In this section when we talk about equality of keys we mean the equiv
alence relation imposed by the comparison and not the operator== on
keys. That is, two keys k1 and k2 are considered to be equal if for
the comparison object comp, comp(k1, k2) == false && comp(k2, k1) ==
false.
4 An associative container supports unique keys if it may contain at
most one element for each key. Otherwise, it supports equal keys.
set and map support unique keys. multiset and multimap support equal
keys.
5 For set and multiset the value type is the same as the key type. For
map and multimap it is equal to pair<const Key, T>.
6 iterator of an associative container is of the bidirectional iterator
category.
7 In the following Table 12, X is an associative container class, a is a
value of X, a_uniq is a value of X when X supports unique keys, and
a_eq is a value of X when X supports multiple keys, i and j satisfy
input iterator requirements and refer to elements of value_type, [i,
j) is a valid range, p is a valid iterator to a, q, q1, q2 are valid
dereferenceable iterators to a, [q1, q2) is a valid range, t is a
value of X::value_type and k is a value of X::key_type.
Table 12--Associative container requirements (in addition to container)
+----------------------------------------------------------------------------------------+
| expression return type assertion/note complexity |
| pre/post-condition |
+----------------------------------------------------------------------------------------+
|X::key_type Key compile time |
| |
|X::key_compare Compare defaults to less<key_type>. compile time |
| |
|X::value_compare a binary pred is the same as key_compare for set and compile time |
| icate type multiset; is an ordering relation on |
| pairs induced by the first component |
| (i.e. Key) for map and multimap. |
+----------------------------------------------------------------------------------------+
|X(c) constructs an empty container; constant |
|X a(c); uses c as a comparison object. |
+----------------------------------------------------------------------------------------+
|X() constructs an empty container; constant |
|X a; uses Compare() as a comparison object. |
+----------------------------------------------------------------------------------------+
|X(i,j,c); constructs an empty container and in NlogN in gen |
|X a(i,j,c); serts elements from the range [i, j) eral (N is the |
| into it; uses c as a comparison ob distance from |
| ject. i to j); lin |
| ear if [i, j) |
| is sorted with |
| value_comp() |
+----------------------------------------------------------------------------------------+
|X(i, j) same as above, but uses Compare() as a same as |
|X a(i, j); comparison object. above |
+----------------------------------------------------------------------------------------+
|a.key_comp() X::key_compare returns the comparison object out of constant |
| which a was constructed. |
+----------------------------------------------------------------------------------------+
|a.value_comp() X::value_compare returns an object of value_compare constant |
| constructed out of the comparison ob |
| ject. |
+----------------------------------------------------------------------------------------+
|a_uniq.insert(t) pair<iterator, inserts t if and only if there is no logarithmic |
| bool> element in the container with key |
| equal to the key of t. The bool com |
| ponent of the returned pair indicates |
| whether the insertion takes place and |
| the iterator component of the pair |
| points to the element with key equal |
| to the key of t. |
+----------------------------------------------------------------------------------------+
---------------------------------------------------------------------------------------------
expression return type assertion/note complexity
pre/post-condition
---------------------------------------------------------------------------------------------
a_eq.insert(t) iterator inserts t and returns the iterator logarithmic
pointing to the newly inserted ele
ment.
---------------------------------------------------------------------------------------------
a.insert(p, t) iterator inserts t if and only if there is logarithmic in
no element with key equal to the general, but amor
key of t in containers with unique tized constant if
keys; always inserts t in contain t is inserted
ers with equal keys. always re right after p.
turns the iterator pointing to the
element with key equal to the key
of t. iterator p is a hint point
ing to where the insert should
start to search.
---------------------------------------------------------------------------------------------
a.insert(i, j) result is not used inserts the elements from the range Nlog(size()+N) (N
[i, j) into the container. is the distance
from i to j) in
general; linear if
[i, j) is sorted
according to val
ue_comp()
---------------------------------------------------------------------------------------------
a.erase(k) size_type erases all the elements in the con log(size()) +
tainer with key equal to k. re count(k)
turns the number of erased ele
ments.
---------------------------------------------------------------------------------------------
a.erase(q) result is not used erases the element pointed to by q. amortized constant
---------------------------------------------------------------------------------------------
a.erase(q1, q2) result is not used erases all the elements in the log(size())+ N
range [q1, q2). where N is the
distance from q1
to q2.
---------------------------------------------------------------------------------------------
a.find(k) iterator; con returns an iterator pointing to an logarithmic
st_iterator for element with the key equal to k, or
constant a a.end() if such an element is not
found.
---------------------------------------------------------------------------------------------
a.count(k) size_type returns the number of elements with log(size())+
key equal to k count(k)
---------------------------------------------------------------------------------------------
a.lower_bound(k) iterator; con returns an iterator pointing to the logarithmic
st_iterator for first element with key not less
constant a than k.
---------------------------------------------------------------------------------------------
a.upper_bound(k) iterator; con returns an iterator pointing to the logarithmic
st_iterator for first element with key greater than
constant a k.
| |
| |
| |
| |
+-------------------------------------------------------------------------------------------+
|a.equal_range(k) pair< itera equivalent to make_pair( logarithmic |
| tor,iterator>; a.lower_bound(k), |
| pair< con a.upper_bound(k)). |
| st_iterator, con |
| st_iterator> for |
| constant a |
+-------------------------------------------------------------------------------------------+
8 The fundamental property of iterators of associative containers is
that they iterate through the containers in the non-descending order
of keys where non-descending is defined by the comparison that was
used to construct them. For any two dereferenceable iterators i and j
such that distance from i to j is positive,
value_comp(*j, *i) == false
9 For associative containers with unique keys the stronger condition
holds,
value_comp(*i, *j) == true.
17.2.3 Implementation types [lib.implementation.types]
1 Certain types defined in this clause are based on other types, but
with added constraints.
17.2.3.1 Enumerated types [lib.enumerated.types]
1 Several types defined in this clause are enumerated types. Each enu
merated type can be implemented as an enumeration or as a synonym for
an enumeration. The enumerated type enumerated can be written:
enum secret {
V0, V1, V2, V3, .....};
typedef secret enumerated;
static const enumerated C0(V0);
static const enumerated C1(V1);
static const enumerated C2(V2);
static const enumerated C3(V3);
.....
2 Here, the names C0, C1, etc. represent enumerated elements for this
particular enumerated type. All such elements have distinct values.
17.2.3.2 Bitmask types [lib.bitmask.types]
1 Several types defined in this clause are bitmask types. Each bitmask
type can be implemented as an enumerated type that overloads certain
operators. The bitmask type bitmask can be written:
enum secret {
V0 = 1 << 0, V1 = 1 << 1, V2 = 1 << 2, V3 = 1 << 3, .....};
typedef secret bitmask;
static const bitmask C0(V0);
static const bitmask C1(V1);
static const bitmask C2(V2);
static const bitmask C3(V3);
.....
bitmask& operator&=(bitmask& X, bitmask Y)
{X = (bitmask)(X & Y); return (X); }
bitmask& operator|=(bitmask& X, bitmask Y)
{X = (bitmask)(X | Y); return (X); }
bitmask& operator^=(bitmask& X, bitmask Y)
{X = (bitmask)(X ^ Y); return (X); }
bitmask operator&(bitmask X, bitmask Y)
{return ((bitmask)(X & Y)); }
bitmask operator|(bitmask X, bitmask Y)
{return ((bitmask)(X | Y)); }
bitmask operator^(bitmask X, bitmask Y)
{return ((bitmask)(X ^ Y)); }
bitmask operator~(bitmask X)
{return ((bitmask)~X); }
2 Here, the names C0, C1, etc. represent bitmask elements for this par
ticular bitmask type. All such elements have distinct values such
that, for any pair Ci and Cj, Ci & Ci is nonzero and Ci & Cj is zero.
3 The following terms apply to objects and values of bitmask types:
--To set a value Y in an object X is to evaluate the expression X |=
Y.
--To clear a value Y in an object X is to evaluate the expression X &=
~Y.
--The value Y is set in the object X if the expression X & Y is
nonzero.
17.2.3.3 Character sequences [lib.character.seq]
1 The Standard C++ library makes widespread use of characters and char
acter sequences that follow a few uniform conventions:
--A letter is any of the 26 lowercase or 26 uppercase letters in the
basic execution character set.4)
--The decimal-point character is the (single-byte) character used by
functions that convert between a (single-byte) character sequence
and a value of one of the floating-point types. It is used in the
character sequence to denote the beginning of a fractional part. It
_________________________
4) Note that this definition differs from the definition in ISO C sub
clause 7.1.1.
is represented in this clause by a period, '.', which is also its
value in the "C" locale, but may change during program execution by
a call to setlocale(int, const char*), declared in <clocale>
(_lib.c.locales_).
--A character sequence is an array object A that can be declared as T
A[N], where T is any of the types char, unsigned char, or signed
char, optionally qualified by any combination of const or volatile.
The initial elements of the array have defined contents up to and
including an element determined by some predicate. A character
sequence can be designated by a pointer value S that points to its
first element.
17.2.3.3.1 Byte strings [lib.byte.strings]
1 A null-terminated byte string, or NTBS, is a character sequence whose
highest-addressed element with defined content has the value zero (the
terminating null character).5)
2 The length of an NTBS is the number of elements that precede the ter
minating null character. An empty NTBS has a length of zero.
3 The value of an NTBS is the sequence of values of the elements up to
and including the terminating null character.
4 A static NTBS is an NTBS with static storage duration.6)
17.2.3.3.2 Multibyte strings [lib.multibyte.strings]
1 A null-terminated multibyte string, or NTMBS, is an NTBS that consti
tutes a sequence of valid multibyte characters, beginning and ending
in the initial shift state.7)
2 A static NTMBS is an NTMBS with static storage duration.
17.2.3.3.3 Wide-character sequences [lib.wide.characters]
that can be declared as T A[N], where T is type wchar_t, optionally
qualified by any combination of const or volatile. The initial ele
ments of the array have defined contents up to and including an ele
ment determined by some predicate. A character sequence can be desig
nated by a pointer value S that designates its first element.
1 A null-terminated wide-character string, or NTWCS, is a wide-character
sequence whose highest-addressed element with defined content has the
_________________________
5) Many of the objects manipulated by function signatures declared in
<cstring> are character sequences or NTBSs. The size of some of these
character sequences is limited by a length value, maintained separate
ly from the character sequence.
6) A string literal, such as "abc", is a static NTBS.
7) An NTBS that contains characters only from the basic execution
character set is also an NTMBS. Each multibyte character then con
sists of a single byte.
value zero.8)
2 The length of an NTWCS is the number of elements that precede the ter
minating null wide character. An empty NTWCS has a length of zero.
3 The value of an NTWCS is the sequence of values of the elements up to
and including the terminating null character.
4 A static NTWCS is an NTWCS with static storage duration.9)
17.2.4 Other conventions [lib.res.and.conventions]
1 This subclause describes several editorial conventions used to
describe the contents of the Standard C++ library. These conventions
are for describing handler functions (_lib.global.pointers_), class
and class template member functions (_lib.functions.within.classes_),
private members (_lib.objects.within.classes_), and convenient names
(_lib.unreserved.names_).
+------- BEGIN BOX 2 -------+
ISSUE: this subclause needs more discussion by the Library WG.
+------- END BOX 2 -------+
17.2.4.1 Handler functions [lib.global.pointers]
1 Certain handler functions are determined by the values stored in
pointer objects within the Standard C++ library. Initially, these
pointer objects store null pointers or designate functions defined in
the Standard C++ library. Other functions, however, when executed at
run time, permit the program to alter these stored values to point at
functions defined in the program.
+------- BEGIN BOX 3 -------+
ISSUE: this overspecification creates a problem for reentrancy
+------- END BOX 3 -------+
17.2.4.2 Functions within classes [lib.functions.within.classes]
1 For the sake of exposition, this clause describes no copy construc
tors, assignment operators, or (non-virtual) destructors with the same
apparent semantics as those that can be generated by default. It is
unspecified whether the implementation provides explicit definitions
for such member function signatures, or for virtual destructors that
can be generated by default.
2 For the sake of exposition, this clause repeats in a derived class
declarations for all the virtual member functions inherited from a
_________________________
8) Many of the objects manipulated by function signatures declared in
<cwchar> are wide-character sequences or NTWCSs.
9) A wide string literal, such as L"abc", is a static NTWCS.
base class. All such declarations are enclosed in a comment that ends
with inherited, as in:
// virtual void do_raise(); inherited
3 If a virtual member function in the base class meets the semantic
requirements of the derived class, it is unspecified whether the
derived class provides an overriding definition for the function sig
nature.
+------- BEGIN BOX 4 -------+
Editorial Proposal: Eliminate the specious ``definitions'' that say
``Behaves the same as ...''
+------- END BOX 4 -------+
17.2.4.3 Private members [lib.objects.within.classes]
1 Objects of certain classes are sometimes required by the external
specifications of their classes to store data, apparently in member
objects. For the sake of exposition, this clause provides representa
tive declarations, and semantic requirements, for private member
objects of classes that meet the external specifications of the
classes. The declarations for such member objects and the definitions
of related member types in this clause are enclosed in a comment that
ends with exposition only, as in:
// streambuf* sb; exposition only
2 Any alternate implementation that provides equivalent external behav
ior is equally acceptable.
17.2.4.4 Convenient names [lib.unreserved.names]
1 Certain types defined in C headers are sometimes needed to express
declarations in other headers, where the required type names are nei
ther defined nor reserved. In such cases, the implementation provides
a synonym for the required type, using a name reserved to the imple
mentation. Such cases are explicitly stated in this clause, and indi
cated by writing the required type name in constant-width italic char
acters.
2 Certain names are sometimes convenient to supply for the sake of expo
sition, in the descriptions in this clause, even though the names are
neither defined nor reserved. In such cases, the implementation
either omits the name, where that is permitted, or provides a name
reserved to the implementation. Such cases are also indicated in this
clause by writing the convenient name in constant-width italic charac
ters.
3 For example:
4 The class filebuf, defined in <fstream>, is described as containing
the private member object:
FILE* file;
5 This notation indicates that the member file is a pointer to the type
FILE, defined in <cstdio>, but the names file and FILE are neither
defined nor reserved in <fstream>. An implementation need not imple
ment class filebuf with an explicit member of type FILE*. If it does
so, it can choose 1) to replace the name file with a name reserved to
the implementation, and 2) to replace FILE with an incomplete type
whose name is reserved, such as in:
struct _Filet* _Fname;
6 If the program needs to have type FILE defined, it must also include
<cstdio>, which completes the definition of _Filet.
17.3 Library-wide requirements [lib.requirements]
1 This subclause specifies requirements that apply to the entire Stan
dard C++ library. Subclauses _lib.language.support_ through
_lib.input.output_ specify the requirements of individual entities
within the library.
2 The following subclauses describe the library's contents and organiza
tion (_lib.organization_), how well-formed C++ programs gain access to
library entities (_lib.using_), constraints on such programs
(_lib.constraints_), and constraints on conforming implementations
(_lib.conforming_).
17.3.1 Library contents and organization [lib.organization]
1 This subclause provides a summary of the entities defined in the Stan
dard C++ library. Subclause _lib.contents_ provides an alphabetical
listing of entities by type, while subclause _lib.headers_ provides an
alphabetical listing of library headers.
17.3.1.1 Library contents [lib.contents]
1 The Standard C++ library provides definitions for the following types
of entities:
--Macros
--Values
--Types
--Templates
--Classes
--Functions
--Objects
2 All library entities shall be defined within the namespace std.
3 The Standard C++ library provides the following standard macros, as
shown in Table 13. The header names (enclosed in < and >) indicate
that the macro may be defined in more than one header. All such defi
nitions shall be equivalent (_basic.def.odr_).
Table 13--Standard Macros
+-----------------------------------------------------------------------------+
|assert LC_COLLATE NULL <cwchar> SIGTERM WCHAR_MIN |
|BUFSIZ LC_CTYPE offsetof SIG_DFL WEOF <cwchar> |
|CLOCKS_PER_SEC LC_MONETARY RAND_MAX SIG_ERR WEOF <cwctype> |
|EDOM LC_NUMERIC SEEK_CUR SIG_IGN _IOFBF |
|EOF LC_TIME SEEK_END stderr _IOLBF |
|ERANGE L_tmpnam SEEK_SET stdin _IONBF |
|EXIT_FAILURE MB_CUR_MAX setjmp stdout __STD_COMPLEX |
|EXIT_SUCCESS NDEBUG SIGABRT TMP_MAX |
|FILENAME_MAX NULL <cstddef> SIGFPE va_arg |
|FOPEN_MAX NULL <cstdio> SIGILL va_end |
|HUGE_VAL NULL <cstring> SIGINT va_start |
|LC_ALL NULL <ctime> SIGSEGV WCHAR_MAX |
+-----------------------------------------------------------------------------+
4 The Standard C++ library provides the following standard values, as
shown in Table 14:
Table 14--Standard Values
+--------------------------------------------------------------+
|CHAR_BIT FLT_DIG LDBL_DIG reserve |
|CHAR_MAX FLT_EPSILON LDBL_EPSILON SCHAR_MAX |
|CHAR_MIN FLT_MANT_DIG LDBL_MANT_DIG SCHAR_MIN |
|DBL_DIG FLT_MAX LDBL_MAX SHRT_MAX |
|DBL_EPSILON FLT_MAX_10_EXP LDBL_MAX_10_EXP SHRT_MIN |
|DBL_MANT_DIG FLT_MAX_EXP LDBL_MAX_EXP UCHAR_MAX |
|DBL_MAX FLT_MIN LDBL_MIN UINT_MAX |
|DBL_MAX_10_EXP FLT_MIN_10_EXP LDBL_MIN_10_EXP ULONG_MAX |
|DBL_MAX_EXP FLT_MIN_DIG LDBL_MIN_DIG USHRT_MAX |
|DBL_MIN FLT_RADIX LONG_MAX |
|DBL_MIN_10_EXP FLT_ROUNDS LONG_MIN |
|DBL_MIN_DIG INT_MAX MB_LEN_MAX |
|default_size INT_MIN NPOS |
+--------------------------------------------------------------+
5 The Standard C++ library provides the following standard types, as
shown in Table 15:
Table 15--Standard Types
+----------------------------------------------------------------------+
|capacity mbstate_t size_t <ctime> wctrans_t |
|clock_t new_handler size_t <stddef> wctype_t |
|div_t ptrdiff_t <stddef> streamoff wint_t <cwchar> |
|FILE ptrdiff_t<cstddef> string wint_t <cwctype> |
|fpos_t sig_atomic_t terminate_handler wint_t <stddef> |
|fvoid_t size_t <cstddef> unexpected_handler wstring |
|jmp_buf size_t <cstdio> va_list |
|ldiv_t size_t <cstring> wchar_t |
+----------------------------------------------------------------------+
6 The Standard C++ library provides the following standard template
classes, as shown in Table 16:
Table 16--Standard Template Classes
+--------------------------------------------------------+
|allocator locale::ctype_byname |
|back_insert_iterator locale::moneypunct |
|basic_convbuf locale::moneypunct_byname |
|basic_filebuf locale::money_get |
|basic_ifstream locale::money_put |
|basic_imanip locale::msg |
|basic_ios locale::msg_byname |
|basic_istream locale::numpunct |
|basic_istringstream locale::num_get |
|basic_istrstream locale::num_put |
|basic_ofstream locale::time_get |
|basic_omanip locale::time_get_byname |
|basic_ostream locale::time_put |
|basic_ostringstream locale::time_put_byname |
|basic_ostrstream map |
|basic_smanip mask_array |
|basic_stdiobuf multimap |
|basic_streambuf multiset |
|basic_string omanip |
|basic_stringbuf ostreambuf_iterator |
|basic_strstreambuf ostream_iterator |
|binary_negate pointer_to_binary_function |
|binder1st pointer_to_unary_function |
|binder2nd priority_queue |
|bits queue |
|deque raw_storage_iterator |
|dyn_array restrictor |
|front_insert_iterator reverse_bidirectional_iterator |
|gslice_array reverse_iterator |
|imanip set |
|indirect_array slice_array |
|insert_iterator smanip |
|istreambuf_iterator stack |
|istream_iterator unary_negate |
|list valarray |
|locale::codecvt vector |
|locale::codecvt_byname wimanip |
|locale::collate womanip |
|locale::collate_byname wsmanip |
|locale::ctype |
+--------------------------------------------------------+
7 The Standard C++ library provides the following standard template
structures, as shown in Table 17:
Table 17--Standard Template Structs
+-------------------------------------------------------------------+
|bidirectional_iterator ios_char_baggage negate |
|binary_function ios_conv_baggage not_equal_to |
|conv_baggage ios_pos_baggage pair |
|divides less plus |
|equal_to less_equal random_access_iterator |
|forward_iterator logical_and times |
|greater logical_not unary_function |
|greater_equal logical_or |
|input_iterator minus |
|ios_baggage modulus |
+-------------------------------------------------------------------+
8 The Standard C++ library provides the following standard template
operator functions, as shown in Table 18. Types shown (enclosed in (
and )) indicate that the given function is overloaded by that type.
Numbers shown (enclosed in [ and ]) indicate how many overloaded func
tions are overloaded by that type.
Table 18--Standard Template Operators
+--------------------------------------------------------------------+
|operator!= (istreambuf_iterator) operator<= (T) |
|operator!= (ostreambuf_iterator) operator<= (valarray) [3] |
|operator!= (T) operator== (deque) |
|operator!= (valarray) [3] operator== (istreambuf_iterator) |
|operator% (valarray) [3] operator== (istream_iterator) |
|operator%= (valarray) [2] operator== (list) |
|operator& (valarray) [3] operator== (map) |
|operator&& (valarray) [3] operator== (multimap) |
|operator&= (valarray) [2] operator== (multiset) |
|operator* (valarray) [3] operator== (ostreambuf_iterator) |
|operator*= (valarray) [2] operator== (pair) |
|operator+ (reverse_iterator) operator== (queue) |
|operator+ (valarray) [3] operator== (restrictor) |
|operator+= (valarray) [2] operator== (reverse_bidir_iter) |
|operator- (reverse_iterator) operator== (reverse_iterator) |
|operator- (valarray) [3] operator== (set) |
|operator-= (valarray) [2] operator== (stack) |
|operator/ (valarray) [3] operator== (valarray) [3] |
|operator/= (valarray) [2] operator== (vector) |
|operator< (deque) operator> (T) |
|operator< (list) operator> (valarray) [3] |
|operator< (map) operator>= (T) |
|operator< (multimap) operator>= (valarray) [3] |
|operator< (multiset) operator>> (imanip) |
|operator< (pair) operator>> (smanip) |
|operator< (restrictor) operator>> (valarray) [3] |
|operator< (reverse_iterator) operator>>=(valarray) [2] |
|operator< (set) operator^ (valarray) [3] |
|operator< (valarray) [3] operator^= (valarray) [2] |
|operator< (vector) operator| (valarray) [3] |
|operator<< (omanip) operator|= (valarray) [2] |
|operator<< (smanip) operator|| (valarray) [3] |
|operator<< (valarray) [3] |
|operator<<=(valarray) [2] |
+--------------------------------------------------------------------+
9 The Standard C++ library provides the following standard template
functions, as shown in Table 19:
Table 19--Standard Template Functions
---------------------------------------------------------
abs (valarray) iterator_category [5]
accumulate [2] lexicographical_compare [2]
acos (valarray) log (valarray)
adjacent_difference [2] log10(valarray)
adjacent_find [2] lower_bound [2]
advance make_heap [2]
allocate make_pair
asin (valarray) max [2]
atan (valarray) max_element [2]
atan2(valarray) [3] merge [2]
back_inserter min [2]
basic_dec min_element [2]
basic_ends mismatch [2]
basic_fixed next_permutation [2]
basic_flush not1
basic_hex not2
basic_internal nth_element [2]
basic_left objconstruct
basic_noshowbase objcopy
basic_noshowpoint objdestroy
basic_noskipws objmove
basic_nouppercase partial_sort [2]
basic_nowshowpos partial_sort_copy [2]
basic_oct partial_sum [2]
basic_resetiosflags partition
basic_right pop_heap [2]
basic_scientific pow (valarray) [3]
basic_setbase prev_permutation [2]
basic_setfill ptr_fun [2]
basic_setiosflags push_heap [2]
basic_setprecision random_shuffle [2]
basic_showbase remove
basic_showpoint remove_copy
basic_showpos remove_copy_if
basic_skipws remove_if
basic_uppercase replace
basic_ws replace_copy
binary_search [2] replace_copy_if
bind1st replace_if
bind2nd reverse
construct reverse_copy
copy rotate
copy_backward rotate_copy
cos (valarray) search [2]
cosh (valarray) set_difference [2]
count set_intersection [2]
count_if set_symmetric_difference [2]
| |
| |
| |
| |
|deallocate set_union [2] |
+-------------------------------------------------------+
+-----------------------------------------------------------------------+
|destroy [2] sin (valarray) |
|distance sinh (valarray) |
|distance_type (istreambuf_iterator) sort [2] |
|distance_type [5] sort_heap [2] |
|equal [2] sqrt (valarray) |
|equal_range [2] stable_partition |
|exp (valarray) stable_sort [2] |
|fill swap |
|fill_n swap_ranges |
|find tan (valarray) |
|find_if tanh (valarray) |
|for_each transform [2] |
|front_inserter uninitialized_copy |
|generate uninitialized_fill_n |
|generate_n unique [2] |
|get_temporary_buffer unique_copy [2] |
|includes [2] unititialized_fill |
|inner_product [2] upper_bound [2] |
|inplace_merge [2] value_type (istreambuf_iterator) |
|inserter value_type (ostreambuf_iterator) |
|iterator_category (istreambuf_iter) value_type [5] |
|iterator_category (ostreambuf_iter) |
+-----------------------------------------------------------------------+
10The Standard C++ library provides the following standard classes, as
shown in Table 20. Type names (enclosed in < and >) indicate that
these are specific instances of templates.
Table 20--Standard Classes
+------------------------------------------------------------------------+
|bad_alloc float_complex range_error |
|bad_cast gslice runtime_error |
|bad_typeid ifstream slice |
|basic_filebuf<char> invalid_argument stdiobuf |
|basic_filebuf<wchar_t> ios streambuf |
|basic_ifstream<char> istdiostream streampos |
|basic_ifstream<wchar_t> istream stringbuf |
|basic_ios<char> istringstream strstreambuf |
|basic_ios<wchar_t> istrstream type_info |
|basic_istream<char> length_error vector<bool,allocator> |
|basic_istream<wchar_t> locale wfilebuf |
|basic_ofstream<char> locale::ctype<char> wifstream |
|basic_ofstream<wchar_t> logic_error wistream |
|basic_ostream<char> long_double_complex wistringstream |
|basic_ostream<wchar_t> ofstream wofstream |
|basic_streambuf<char> ostdiostream wostream |
|basic_streambuf<wchar_t> ostream wostringstream |
|bitstring ostringstream wstreambuf |
|domain_error ostrstream wstringbuf |
|double_complex out_of_range |
|exception overflow_error |
|filebuf ptr_dyn_array |
+------------------------------------------------------------------------+
11The Standard C++ library provides the following standard structures,
as shown in Table 21:
Table 21--Standard Structs
+-----------------------------------------------------------+
|bidirectional_iterator_tag ios_pos_baggage<streampos> |
|conv_baggage<wchar_t> ios_pos_baggage<wstreampos> |
|empty lconv |
|forward_iterator_tag locale::ctype_base |
|input_iterator_tag output_iterator |
|ios_baggage<char> output_iterator_tag |
|ios_baggage<wchar_t> random_access_iterator_tag |
|ios_char_baggage<char> tm <ctime> |
|ios_char_baggage<wchar_t> tm <cwchar> |
|ios_conv_baggage<wstreampos> |
+-----------------------------------------------------------+
12The Standard C++ library provides the following standard operator
functions, as shown in Table 22:
Table 22--Standard Operator functions
+----------------------------------------------------------------------------+
|operator delete operator/ (double_complex) [3] |
|operator delete[] operator/ (float_complex) [3] |
|operator new operator/ (long_double_complex) [3] |
|operator new (void*) operator/= (double_complex) |
|operator new[] operator/= (float_complex) |
|operator new[] (void*) operator/= (long_double_complex) |
|operator!= (basic_string) [5] operator< (empty) |
|operator!= (double_complex) [3] operator< (vector<bool,allocator>) |
|operator!= (float_complex) [3] operator<< (basic_string) |
|operator!= (long_double_complex) [3] operator<< (bits) |
|operator& (bits) operator<< (bit_string) |
|operator& (bit_string) operator<< (double_complex) |
|operator* (double_complex) [3] operator<< (float_complex) |
|operator* (float_complex) [3] operator<< (locale) |
|operator* (long_double_complex) [3] operator<< (long_double_complex) |
|operator*= (double_complex) operator== (basic_string) [5] |
|operator*= (float_complex) operator== (double_complex) [3] |
|operator*= (long_double_complex) operator== (empty) |
|operator+ (basic_string) [5] operator== (float_complex) [3] |
|operator+ (bit_string) operator== (long_double_complex) [3] |
|operator+ (double_complex) [4] operator== (vector<bool,allocator>) |
|operator+ (dyn_array) [3] operator>> (basic_string) |
|operator+ (float_complex) [4] operator>> (bits) |
|operator+ (long_double_complex) [4] operator>> (bit_string) |
|operator+ (ptr_dyn_array) [3] operator>> (double_complex) |
|operator+= (double_complex) operator>> (float_complex) |
|operator+= (float_complex) operator>> (locale) |
|operator+= (long_double_complex) operator>> (long_double_complex) |
|operator- (double_complex) [4] operator^ (bits) |
|operator- (float_complex) [4] operator^ (bit_string) |
|operator- (long_double_complex) [4] operator| (bits) |
|operator-= (double_complex) operator| (bit_string) |
|operator-= (float_complex) |
|operator-= (long_double_complex) |
+----------------------------------------------------------------------------+
13The Standard C++ library provides the following standard functions, as
shown in Table 23:
Table 23--Standard Functions
----------------------------------------------------------
abort noshowpos
abs noskipws
abs (double_complex) nouppercase
abs (float_complex) oct
abs (long_double_complex) perror
acos polar(double_complex)
arg (double_complex) polar(float_complex)
arg (float_complex) polar(long_double_complex)
arg (long_double_complex) pow
asctime pow (double_complex)
asin pow (float_complex)
atan pow (long_double_complex)
atan2 printf
atexit putc
atof puts
atoi putwc
atol putwchar
bsearch qsort
btowc raise
calloc rand
ceil real (double_complex)
clearerr real (float_complex)
clock real (long_double_complex)
conj (double_complex) realloc
conj (float_complex) remove
conj (long_double_complex) rename
cos resetiosflags
cos (double_complex) rewind
cos (float_complex) right
cos (long_double_complex) scanf
cosh scientific
cosh (double_complex) setbase
cosh (float_complex) setbuf
cosh (long_double_complex) setfill
ctime setiosflags
dec setlocale
difftime setprecision
div setvbuf
endl setw
ends set_new_handler
exit set_terminate
exp set_unexpected
exp (double_complex) showbase
exp (float_complex) showpoint
exp (long_double_complex) showpos
fabs signal
fclose sin
| |
| |
| |
| |
|feof sin (double_complex) |
+--------------------------------------------------------+
----------------------------------------------------------
ferror sin (float_complex)
fflush sin (long_double_complex)
fgetc sinh
fgetpos sinh (double_complex)
fgets sinh (float_complex)
fgetwc sinh (long_double_complex)
fgetws skipws
fixed sprintf
floor sqrt
flush sqrt (double_complex)
fmod sqrt (float_complex)
fopen sqrt (long_double_complex)
fprintf srand
fputc sscanf
fputs strcat
fputwc strchr
fputws strcmp
fread strcoll
free strcpy
freopen strcspn
frexp strerror
fscanf strftime
fseek strlen
fsetpos strncat
ftell strncmp
fwide strncpy
fwprintf stroul
fwrite strpbrk
fwscanf strrchr
getc strspn
getchar strstr
getenv strtod
getline strtok
gets strtol
getwc strxfrm
getwchar swprintf
gmtime swscanf
hex system
imag (double_complex) tan
imag (float_complex) tanh
imag (long_double_complex) terminate
internal time
isalnum tmpfile
isalpha tmpfile
iscntrl tmpnam
isdigit tolower
isgraph toupper
islower towctrans
isprint towlower
ispunct towupper
isspace unexpected
| |
| |
| |
| |
|isupper ungetc |
+--------------------------------------------------------+
+-----------------------------------------------------+
|iswalnum ungetwc |
|iswalpha uppercase |
|iswcntrl vfwprintf |
|iswctype vprintf |
|iswdigit vprintf |
|iswgraph vsprintf |
|iswlower vswprintf |
|iswprint vwprintf |
|iswpunct wcrtomb |
|iswspace wcscat |
|iswupper wcschr |
|iswxdigit wcscmp |
|isxdigit wcscoll |
|iterator_category(output_iterator) wcscpy |
|labs wcscspn |
|ldexp wcsftime |
|ldiv wcslen |
|left wcsncat |
|localeconv wcsncmp |
|localtime wcsncpy |
|log wcspbrk |
|log (double_complex) wcsrchr |
|log (float_complex) wcsrtombs |
|log (long_double_complex) wcsspn |
|log10 wcsstr |
|longjmp wcstod |
|malloc wcstok |
|mblen wcstol |
|mbrlen wcstombs |
|mbrtowc wcstoul |
|mbsinit wcsxfrm |
|mbsrtowcs wctob |
|mbstowcs wctomb |
|mbtowc wctrans |
|memchr wctype |
|memcmp wmemchr |
|memcpy wmemcmp |
|memmove wmemcpy |
|memset wmemmove |
|mktime wmemset |
|modf wprintf |
|norm (double_complex) ws |
|norm (float_complex) wscanf |
|norm (long_double_complex) _double_complex |
|noshowbase _float_complex |
|noshowpoint |
+-----------------------------------------------------+
14The Standard C++ library provides the following standard objects, as
shown in Table 24:
Table 24--Standard Objects
+---------------------------------+
|cerr cin clog cout errno |
+---------------------------------+
17.3.1.2 Headers [lib.headers]
1 The elements of the Standard C++ library are declared or defined (as
appropriate) in a header.10)
2 The Standard C++ library provides the following C++ headers, as shown
in Table 25:
+------- BEGIN BOX 5 -------+
Header names were no specified as part of the STL proposal.
Therefore, header names of the form <stl xxx (TBD)> are temporary
placeholders, and subject to change pending Library WG discussion.
+------- END BOX 5 -------+
Table 25--C++ Library Headers
+----------------------------------------------------------------------------+
|<bits> <ios> <sstream> <stl memory (TBD)> |
|<bitstring> <iostream> <stddef> <stl numerics (TBD)> |
|<complex> <istream> <stdexcept> <streambuf> |
|<cstream> <locale> <stl algorithms (TBD)> <string> |
|<dynarray> <memory> <stl containers (TBD)> <strstream> |
|<exception> <new> <stl core (TBD)> <typeinfo> |
|<fstream> <ostream> <stl functional (TBD)> <valarray> |
|<iomanip> <ptrdynarray> <stl iterators (TBD)> |
+----------------------------------------------------------------------------+
3 The facilities of the Standard C Library are provided in 18 additional
headers, as shown in Table 26:
_________________________
10) A header is not necessarily a source file, nor are the sequences
delimited by < and > in header names necessarily valid source file
names.
Table 26--C++ Headers for C Library Facilities
+--------------------------------------------------+
|<cassert> <ciso646> <csetjmp> <cstdio> <cwchar> |
|<cctype> <climits> <csignal> <cstdlib> <cwctype> |
|<cerrno> <clocale> <cstdarg> <cstring> |
|<cfloat> <cmath> <cstddef> <ctime> |
+--------------------------------------------------+
+------- BEGIN BOX 6 -------+
Header <ciso646> is not needed: see _lex.key_, Table 4
+------- END BOX 6 -------+
4 The contents of each header cname shall be the same as that of the
corresponding header name.h, as specified in ISO C (Clause 4), or
Amendment 1, (Clause 7), as appropriate. In this C++ library, how
ever, the declarations and definitions are within namespace scope
(_basic.scope.namespace_) of the namespace std. Subclause
_diff.library_ describes the effects of using the name.h (C header)
form in a C++ program.
17.3.1.3 Freestanding implementations [lib.compliance]
1 Two kinds of implementations are defined: hosted and freestanding
(_intro.compliance_). For a hosted implementation, this International
Standard defines the set of available headers.
2 A freestanding implementation is one in which execution may take place
without the benefit of an operating system, and has an implementation-
defined set of headers. This set shall include at least the following
8 headers:
+------- BEGIN BOX 7 -------+
TBS. Requires a definition of library support for a freestanding
environment.
+------- END BOX 7 -------+
--the headers <new>, <exception>, and <typeinfo> that provide C++ lan
guage support (as described in _lib.language.support_)
--the C++ headers <cfloat>, <climits>, <cstdarg>, and <cstddef>
--a version of the C++ header <cstdlib> that declares at least the
functions abort, atexit, and exit.
17.3.2 Using the library [lib.using]
1 This subclause describes how a C++ program gains access to the facili
ties of the Standard C++ library. Subclause _lib.using.headers_
describes effects during translation phase 4, while subclause
_lib.using.linkage_ describes effects during phase 8 (_lex.phases_).
17.3.2.1 Headers [lib.using.headers]
1 The entities in the Standard C++ library are defined in headers, whose
contents are made available to a translation unit when it contains the
appropriate #include preprocessing directive (_cpp.include_).
2 A translation unit may include library headers in any order (_lex_).
Each may be included more than once, with no effect different from
being included exactly once, except that the effect of including
either <cassert> or <assert.h> depends each time on the lexically cur
rent definition of NDEBUG.
3 A translation unit shall include a header only outside of any external
declaration or definition, and shall include the header lexically
before the first reference to any of the entities it declares or first
defines in that translation unit.
17.3.2.2 Linkage [lib.using.linkage]
1 Entities in the Standard C++ library have external linkage
(_basic.link_). Unless otherwise specified, objects and functions
have the default extern "C++" linkage (_dcl.link_).
2 Objects and functions defined in the library and required by a C++
program are included in the program prior to program startup.
SEE ALSO: replacement functions (_lib.replacement.functions_), run-
time changes (_lib.handler.functions_).
17.3.3 Constraints on programs [lib.constraints]
1 This subclause describes restrictions on C++ programs that use the
facilities of the Standard C++ library. The following subclauses
specify constraints on the program's namespace (_lib.reserved.names_),
its use of headers (_lib.alt.headers_), classes derived from standard
library classes (_lib.derived.classes_), definitions of replacement
functions (_lib.replacement.functions_), and installation of handler
functions during execution (_lib.handler.functions_).
17.3.3.1 Reserved names [lib.reserved.names]
1 The Standard C++ library reserves the following kinds of names:
--Macros
--Global names
--Names with external linkage
2 If the program declares or defines a name in a context where it is
reserved, other than as explicitly allowed by this clause, the behav
ior is undefined.
17.3.3.1.1 Macro names [lib.macro.names]
1 Each name defined as a macro in a header is reserved to the implemen
tation for any use if the translation unit includes the header.11)
2 A translation unit that includes a header shall not contain any macros
that define names declared or defined in that header. Nor shall such
a translation unit define macros for names lexically identical to key
words.
17.3.3.1.2 Global names [lib.global.names]
1 Each header also optionally declares or defines names which are always
reserved to the implementation for any use and names reserved to the
implementation for use at file scope.
2 Certain sets of names and function signatures are reserved whether or
not a translation unit includes a header:
3 Each name that begins with an underscore and either an uppercase let
ter or another underscore (_lex.key_) is reserved to the implementa
tion for any use.
4 Each name that begins with an underscore is reserved to the implemen
tation for use as a name with file scope or within the namespace std
in the ordinary name space.
17.3.3.1.3 External linkage [lib.extern.names]
1 Each name declared as an object with external linkage in a header is
reserved to the implementation to designate that library object with
external linkage.12)
2 Each global function signature declared with external linkage in a
header is reserved to the implementation to designate that function
signature with external linkage. 13)
3 Each name having two consecutive underscores (_lex.key_) is reserved
to the implementation for use as a name with both extern "C" and
_________________________
11) It is not permissible to remove a library macro definition by us
ing the #undef directive.
12) The list of such reserved names includes errno, declared or de
fined in <cerrno>.
13) The list of such reserved function signatures with external link
age includes setjmp(jmp_buf), declared or defined in <csetjmp>, and
va_end(va_list), declared or defined in <cstdarg>.
extern "C++" linkage.
17.3.3.2 Headers [lib.alt.headers]
1 If a file has a name equivalent to the derived file name for one of
the Standard C++ library headers, is not provided as part of the
implementation, and is placed in any of the standard places for a
source file to be included (_cpp.include_), the behavior is undefined.
17.3.3.3 Derived classes [lib.derived.classes]
1 Virtual member function signatures defined for a base class in the
Standard C++ library may be overridden in a derived class by defini
tions in the program.
17.3.3.4 Replacement functions [lib.replacement.functions]
1 This clause describes the behavior of numerous functions defined by
the Standard C++ library. Under some circumstances, however, certain
of these function descriptions also apply to replacement functions
defined in the program (_lib.definitions_).
2 A C++ program may provide the definition for any of four dynamic mem
ory allocation function signatures declared in <new>
(_basic.stc.dynamic_, _lib.language.support_):14)
--operator new(size_t)
--operator new[](size_t)
--operator delete(void*)
--operator delete[](void*)
3 The program's definitions are used instead of the default versions
supplied by the implementation (_dcl.fct.def_). Such replacement
occurs prior to program startup (_basic.def.odr_, _basic.start_).
17.3.3.5 Handler functions [lib.handler.functions]
1 The Standard C++ library provides default versions of the three han
dler functions (_lib.language.support_):
--new_handler
--unexpected_handler
--terminate_handler
2 A C++ program may install different handler functions during execu
tion, by supplying a pointer to a function defined in the program or
the library as an argument to (respectively):
--set_new_handler
--set_unexpected
--set_terminate
3
17.3.3.6 Function arguments [lib.res.on.arguments]
1 Each of the following statements applies to all arguments to functions
defined in the Standard C++ library, unless explicitly stated other
wise in this clause.
--If an argument to a function has an invalid value (such as a value
outside the domain of the function, or a pointer invalid for its
intended use), the behavior is undefined.
--If a function argument is described as being an array, the pointer
actually passed to the function shall have a value such that all
address computations and accesses to objects (that would be valid if
the pointer did point to the first element of such an array) are in
fact valid.
17.3.4 Conforming implementations [lib.conforming]
1 This subclause describes the constraints upon, and latitude of, imple
mentations of the Standard C++ library. The following subclauses
describe an implementation's use of headers (_lib.res.on.headers_),
macros (_lib.res.on.macro.definitions_), global functions
(_lib.global.functions_), member functions (_lib.member.functions_),
access specifiers (_lib.protection.within.classes_), class derivation
(_lib.derivation_), and exceptions (_lib.res.on.exception.handling_).
+------- BEGIN BOX 8 -------+
ISSUE - all of these have to be discussed by the Library WG
+------- END BOX 8 -------+
17.3.4.1 Headers [lib.res.on.headers]
1 Certain types and macros are defined in more than one header. For
such an entity, a second or subsequent header that also defines it may
be included after the header that provides its initial definition.
2 None of the C headers includes any of the other headers, except that
each C header includes its corresponding C++ header, as described
above. None of the C++ headers includes any of the C headers. How
ever, any of the C++ headers can include any of the other C++ headers,
and must include a C++ header that contains any needed definition.14)
_________________________
14) Including any one of the C++ headers can introduce all of the C++
headers into a translation unit, or just the one that is named in the
#include preprocessing directive.
17.3.4.2 Restrictions on macro [lib.res.on.macro.definitions]
definitions
1 Only the names or global function signatures described in subclause
_lib.TBD_ are reserved to the implementation.15)
2 All object-like macros defined by the Standard C++ library and
described in this clause as expanding to integral constant expressions
are also suitable for use in #if preprocessing directives, unless
explicitly stated otherwise.
17.3.4.3 Global functions [lib.global.functions]
1 A call to a global function signature described in this clause behaves
the same as if the implementation declares no additional global func
tion signatures.16)
17.3.4.4 Member functions [lib.member.functions]
1 An implementation can declare additional non-virtual member function
signatures within a class:
--by adding arguments with default values to a member function signa
ture described in this clause; Hence, taking the address of a member
function has an unspecified type. The same latitude does not extend
to the implementation of virtual or global functions, however.
--by replacing a member function signature with default values by two
or more member function signatures with equivalent behavior;
--by adding a member function signature for a member function name
described in this clause.
2 A call to a member function signature described in this clause behaves
the same as if the implementation declares no additional member func
tion signatures.17)
_________________________
15) A global function cannot be declared by the implementation as tak
ing additional default arguments. Also, the use of masking macros for
function signatures declared in C headers is disallowed, notwithstand
ing the latitude granted in subclause 7.1.7 of the C Standard. The
use of a masking macro can often be replaced by defining the function
signature as inline.
16) A valid C++ program always calls the expected library global func
tion. An implementation may also define additional global functions
that would otherwise not be called by a valid C++ program.
17) A valid C++ program always calls the expected library member func
tion, or one with equivalent behavior. An implementation may also de
fine additional member functions that would otherwise not be called by
a valid C++ program.
17.3.4.5 Reentrancy [lib.reentrancy]
1 Which of the functions in the Standard C++ Library are not reentrant
subroutines is implementation-defined.
17.3.4.6 Protection within [lib.protection.within.classes]
classes
1 It is unspecified whether a member described in this clause as private
is private, protected, or public. It is unspecified whether a member
described as protected is protected or public. A member described as
public is always public.
2 It is unspecified whether a function signature or class described in
this clause is a friend of another class described in this clause.
17.3.4.7 Derived classes [lib.derivation]
1 Certain classes defined in this clause are derived from other classes
in the Standard C++ library:
--It is unspecified whether a class described in this clause as a base
class is itself derived from other base classes (with names reserved
to the implementation).
--It is unspecified whether a class described in this clause as
derived from another class is derived from that class directly, or
through other classes (with names reserved to the implementation)
that are derived from the specified base class.
2 In any case:
--A base class described as virtual in this clause is always virtual;
--A base class described as non-virtual in this clause is never vir
tual;
--Unless explicitly stated otherwise, types with distinct names in
this clause are distinct types.18)
17.3.4.8 Restrictions on [lib.res.on.exception.handling]
exception handling
1 Any of the functions defined in the Standard C++ library can report a
failure to allocate storage by throwing an exception of type
bad_alloc, or a class derived from bad_alloc.
2 Otherwise, none of the functions defined in the Standard C++ library
throw an exception that must be caught outside the function, unless
explicitly stated otherwise.
_________________________
18) An implicit exception to this rule are types described as synonyms
for basic integral types, such as size_t and streamoff.
+------- BEGIN BOX 9 -------+
ISSUE: aren't these two statements conveyed by exception specifica
tions?
+------- END BOX 9 -------+
3 None of the functions defined in the Standard C++ library catch any
exceptions, unless explicitly stated otherwise. A function can catch
an exception not documented in this clause provided it rethrows the
exception.
+------- BEGIN BOX 10 -------+
ISSUE: this prevents implementations from using their own exceptions
within the library
+------- END BOX 10 -------+