[library] - C++11 → C++14

Files changed (1) hide show

tmp/tmpjdp1v047/{from.md → to.md} +104 -42

tmp/tmpjdp1v047/{from.md → to.md} RENAMED Viewed

@@ -191,58 +191,64 @@ terminating null character type value `charT()`
 a class member function ([[class.mfct]]) that 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]]).
-#### 19 replacement function <a id="defns.replacement">[[defns.replacement]]</a>
 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 definitions of all translation units (
 [[basic.link]]).
-#### 20 repositional stream <a id="defns.repositional.stream">[[defns.repositional.stream]]</a>
 a stream (described in Clause  [[input.output]]) that can seek to a
 position that was previously encountered
-#### 21 required behavior <a id="defns.required.behavior">[[defns.required.behavior]]</a>
 a description of *replacement function* and *handler function* semantics
 applicable to both the behavior provided by the implementation and the
 behavior of any such function definition in the program
 If such a function defined in a C++program fails to meet the required
 behavior when it executes, the behavior is undefined.
-#### 22 reserved function <a id="defns.reserved.function">[[defns.reserved.function]]</a>
 a function, specified as part of the C++standard library, that must be
 defined by the implementation
 If a C++program provides a definition for any reserved function, the
 results are undefined.
-#### 23 stable algorithm <a id="defns.stable">[[defns.stable]]</a>
 an algorithm that preserves, as appropriate to the particular algorithm,
 the order of elements
 Requirements for stable algorithms are given in  [[algorithm.stable]].
-#### 24 traits class <a id="defns.traits">[[defns.traits]]</a>
 a class that encapsulates a set of types and functions necessary for
 class templates and function templates to manipulate objects of types
 for which they are instantiated
 Traits classes defined in Clauses  [[strings]], [[localization]] and
 [[input.output]] are *character traits*, which provide the character
 handling support needed by the string and iostream classes.
-#### 25 unblock <a id="defns.unblock">[[defns.unblock]]</a>
 place a thread in the unblocked state
-#### 26 valid but unspecified state <a id="defns.valid">[[defns.valid]]</a>
 an object state that is not specified except that the object’s
 invariants are met and operations on the object behave as specified for
 its type
 If an object `x` of type `std::vector<int>` is in a valid but
@@ -316,11 +322,11 @@ Requirements are stated in terms of well-defined expressions that define
 valid terms of the types that satisfy the requirements. For every set of
 well-defined expression requirements there is a table that specifies an
 initial set of the valid expressions and their semantics. Any generic
 algorithm (Clause  [[algorithms]]) that uses the well-defined expression
 requirements is described in terms of the valid expressions for its
-formal type parameters.
 Template argument requirements are sometimes referenced by name. See
 [[type.descriptions]].
 In some cases the semantic requirements are presented as C++code. Such
@@ -495,21 +501,22 @@ bitmask{}& operator^=(bitmask{}& X, bitmask{} Y) {
   X = X ^ Y; return X;
 }
 ```
 Here, the names *C0*, *C1*, etc. represent *bitmask elements* for this
-particular 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.
 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.
 ##### Character sequences <a id="character.seq">[[character.seq]]</a>
 The C standard library makes widespread use of characters and character
@@ -638,11 +645,11 @@ function `::std::G` is meant.
 #### Headers <a id="headers">[[headers]]</a>
 Each element of the C++standard library is declared or defined (as
 appropriate) in a *header*.[^16]
-The C++standard library provides 52 *C++library headers*, as shown in
 Table  [[tab:cpp.library.headers]].
 **Table: C++library headers** <a id="tab:cpp.library.headers">[tab:cpp.library.headers]</a>
 |                        |                      |             |                      |                   |
@@ -755,11 +762,11 @@ either `<cassert>` or `<assert.h>` depends each time on the lexically
 current definition of `NDEBUG`.[^20]
 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 in that translation unit to any of the entities
-declared in that header.
 #### Linkage <a id="using.linkage">[[using.linkage]]</a>
 Entities in the C++standard library have external linkage (
 [[basic.link]]). Unless otherwise specified, objects and functions have
@@ -855,15 +862,15 @@ signatures is called using the default argument ([[dcl.fct.default]]).
 **Table: `Destructible` requirements** <a id="destructible">[destructible]</a>
 |          |                                                                       |
-| ------------- | --------------------------------------------------------------------- |
-| `u.$\sim$T()` | All resources owned by `u` are reclaimed, no exception is propagated. |
-#### Swappable requirements <a id="swappable.requirements">[[swappable.requirements]]</a>
 This subclause provides definitions for swappable types and expressions.
 In these definitions, let `t` denote an expression of type `T`, and let
 `u` denote an expression of type `U`.
@@ -897,12 +904,13 @@ evaluation context.
 An rvalue or lvalue `t` is *swappable* if and only if `t` is swappable
 with any rvalue or lvalue, respectively, of type `T`.
 A type `X` satisfying any of the iterator requirements (
-[[iterator.requirements]]) is *ValueSwappable* if, for any
-dereferenceable object `x` of type `X`, `*x` is swappable.
 User code can ensure that the evaluation of `swap` calls is performed in
 an appropriate context under the various conditions as follows:
 ``` cpp
@@ -1007,12 +1015,12 @@ lvalue of type `Key`, and `k` is a value of a type convertible to
 (possibly `const`) `Key`.
 **Table: `Hash` requirements** <a id="hash">[hash]</a>
 |        |          |                                                                                                                                                                                                                                                                                                                                                                                                                                                   |
-| ------ | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `h(k)` | `size_t` | The value returned shall depend only on the argument `k`. \enternote Thus all evaluations of the expression `h(k)` with the same value for `k` yield the same result. \exitnote \enternote For two different values `t1` and `t2`, the probability that `h(t1)` and `h(t2)` compare equal should be very small, approaching `1.0 / numeric_limits<size_t>::max()`. \exitnote |
 | `h(u)` | `size_t` | Shall not modify `u`.                                                                                                                                                                                                                                                                                                                                                                                                                             |
 #### Allocator requirements <a id="allocator.requirements">[[allocator.requirements]]</a>
@@ -1052,17 +1060,54 @@ class template instantiation of the form `SomeAllocator<T, Args>`, where
 `rebind` member template, the standard `allocator_traits` template uses
 `SomeAllocator<U, Args>` in place of `Allocator::{}rebind<U>::other` by
 default. For allocator types that are not template instantiations of the
 above form, no default is provided.
-The `X::pointer`, `X::const_pointer`, `X::void_pointer`, and
-`X::const_void_pointer` types shall satisfy the requirements of
-`NullablePointer` ([[nullablepointer.requirements]]). No constructor,
-comparison operator, copy operation, move operation, or swap operation
-on these types shall exit via an exception. `X::pointer` and
-`X::const_pointer` shall also satisfy the requirements for a random
-access iterator ([[iterator.requirements]]).
 An allocator may constrain the types on which it can be instantiated and
 the arguments for which its `construct` member may be called. If a type
 cannot be used with a particular allocator, the allocator class or the
 call to `construct` may fail to instantiate.
@@ -1080,10 +1125,15 @@ struct SimpleAllocator {
   template <class T> SimpleAllocator(const SimpleAllocator<T>& other);
   Tp* allocate(std::size_t n);
   void deallocate(Tp* p, std::size_t n);
 };
 ```
 If the alignment associated with a specific over-aligned type is not
 supported by an allocator, instantiation of the allocator for that type
 may fail. The allocator also may silently ignore the requested
@@ -1223,11 +1273,11 @@ Clauses  [[language.support]] through  [[thread]] and Annex  [[depr]]
 describe the behavior of numerous functions defined by the C++standard
 library. Under some circumstances, however, certain of these function
 descriptions also apply to replacement functions defined in the
 program ([[definitions]]).
-A C++program may provide the definition for any of eight dynamic memory
 allocation function signatures declared in header `<new>` (
 [[basic.stc.dynamic]], [[support.dynamic]]):
 - `operator new(std::size_t)`
 - `operator new(std::size_t, const std::nothrow_t&)`
@@ -1235,10 +1285,14 @@ allocation function signatures declared in header `<new>` (
 - `operator new[](std::size_t, const std::nothrow_t&)`
 - `operator delete(void*)`
 - `operator delete(void*, const std::nothrow_t&)`
 - `operator delete[](void*)`
 - `operator delete[](void*, const std::nothrow_t&)`
 The program’s definitions are used instead of the default versions
 supplied by the implementation ([[support.dynamic]]). Such replacement
 occurs prior to program startup ([[basic.def.odr]], [[basic.start]]).
 The program’s definitions shall not be specified as `inline`. No
@@ -1409,17 +1463,19 @@ signature with additional default arguments.
 Unless otherwise specified, global and non-member functions in the
 standard library shall not use functions from another namespace which
 are found through *argument-dependent name lookup* (
 [[basic.lookup.argdep]]). The phrase “unless otherwise specified” is
 intended to allow argument-dependent lookup in cases like that of
-`ostream_iterator`s: *Effects:*
 ``` cpp
 *out_stream << value;
 if (delim != 0)
   *out_stream << delim;
-return (*this);
 ```
 #### Member functions <a id="member.functions">[[member.functions]]</a>
 It is unspecified whether any member functions in the C++standard
@@ -1439,26 +1495,30 @@ A call to a member function signature described in the C++standard
 library behaves as if the implementation declares no additional member
 function signatures.[^29]
 #### `constexpr` functions and constructors <a id="constexpr.functions">[[constexpr.functions]]</a>
-Within any header that provides any non-defining declarations of
-`constexpr` functions or constructors an implementation shall provide
-corresponding definitions.
 #### Requirements for stable algorithms <a id="algorithm.stable">[[algorithm.stable]]</a>
 When the requirements for an algorithm state that it is “stable” without
 further elaboration, it means:
 - For the *sort* algorithms the relative order of equivalent elements is
   preserved.
-- For the *remove* algorithms the relative order of the elements that
-  are not removed is preserved.
 - For the *merge* algorithms, for equivalent elements in the original
-  two ranges, the elements from the first range precede the elements
-  from the second range.
 #### Reentrancy <a id="reentrancy">[[reentrancy]]</a>
 Except where explicitly specified in this standard, it is
 *implementation-defined* which functions in the Standard C++ library may
@@ -1636,10 +1696,11 @@ objects shall be placed in a valid but unspecified state.
 [conventions]: #conventions
 [cpp.include]: cpp.md#cpp.include
 [cstdint]: language.md#cstdint
 [dcl.array]: dcl.md#dcl.array
 [dcl.attr]: dcl.md#dcl.attr
 [dcl.fct.default]: dcl.md#dcl.fct.default
 [dcl.fct.spec]: dcl.md#dcl.fct.spec
 [dcl.init]: dcl.md#dcl.init
 [dcl.link]: dcl.md#dcl.link
 [definitions]: #definitions
@@ -1700,10 +1761,11 @@ objects shall be placed in a valid but unspecified state.
 [nullablepointer.requirements]: #nullablepointer.requirements
 [numeric.requirements]: numerics.md#numeric.requirements
 [numerics]: numerics.md#numerics
 [objects.within.classes]: #objects.within.classes
 [organization]: #organization
 [over.match]: over.md#over.match
 [over.oper]: over.md#over.oper
 [protection.within.classes]: #protection.within.classes
 [re]: re.md#re
 [reentrancy]: #reentrancy
@@ -1836,11 +1898,11 @@ objects shall be placed in a valid but unspecified state.
 [^20]: This is the same as the Standard C library.
 [^21]: The only reliable way to declare an object or function signature
     from the Standard C library is by including the header that declares
-    it, notwithstanding the latitude granted in 7.1.7 of the C Standard.
 [^22]: Any library code that instantiates other library templates must
     be prepared to work adequately with any user-supplied specialization
     that meets the minimum requirements of the Standard.

 a class member function ([[class.mfct]]) that 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]]).
+#### 19 referenceable type <a id="defns.referenceable">[[defns.referenceable]]</a>
+An object type, a function type that does not have cv-qualifiers or a
+*ref-qualifier*, or a reference type. The term describes a type to which
+a reference can be created, including reference types.
+#### 20 replacement function <a id="defns.replacement">[[defns.replacement]]</a>
 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 definitions of all translation units (
 [[basic.link]]).
+#### 21 repositional stream <a id="defns.repositional.stream">[[defns.repositional.stream]]</a>
 a stream (described in Clause  [[input.output]]) that can seek to a
 position that was previously encountered
+#### 22 required behavior <a id="defns.required.behavior">[[defns.required.behavior]]</a>
 a description of *replacement function* and *handler function* semantics
 applicable to both the behavior provided by the implementation and the
 behavior of any such function definition in the program
 If such a function defined in a C++program fails to meet the required
 behavior when it executes, the behavior is undefined.
+#### 23 reserved function <a id="defns.reserved.function">[[defns.reserved.function]]</a>
 a function, specified as part of the C++standard library, that must be
 defined by the implementation
 If a C++program provides a definition for any reserved function, the
 results are undefined.
+#### 24 stable algorithm <a id="defns.stable">[[defns.stable]]</a>
 an algorithm that preserves, as appropriate to the particular algorithm,
 the order of elements
 Requirements for stable algorithms are given in  [[algorithm.stable]].
+#### 25 traits class <a id="defns.traits">[[defns.traits]]</a>
 a class that encapsulates a set of types and functions necessary for
 class templates and function templates to manipulate objects of types
 for which they are instantiated
 Traits classes defined in Clauses  [[strings]], [[localization]] and
 [[input.output]] are *character traits*, which provide the character
 handling support needed by the string and iostream classes.
+#### 26 unblock <a id="defns.unblock">[[defns.unblock]]</a>
 place a thread in the unblocked state
+#### 27 valid but unspecified state <a id="defns.valid">[[defns.valid]]</a>
 an object state that is not specified except that the object’s
 invariants are met and operations on the object behave as specified for
 its type
 If an object `x` of type `std::vector<int>` is in a valid but
 valid terms of the types that satisfy the requirements. For every set of
 well-defined expression requirements there is a table that specifies an
 initial set of the valid expressions and their semantics. Any generic
 algorithm (Clause  [[algorithms]]) that uses the well-defined expression
 requirements is described in terms of the valid expressions for its
+template type parameters.
 Template argument requirements are sometimes referenced by name. See
 [[type.descriptions]].
 In some cases the semantic requirements are presented as C++code. Such
   X = X ^ Y; return X;
 }
 ```
 Here, the names *C0*, *C1*, etc. represent *bitmask elements* for this
+particular bitmask type. All such elements have distinct, nonzero values
+such that, for any pair *Ci* and *Cj* where *i* != *j*, *Ci* & *Ci* is
+nonzero and *Ci* & *Cj* is zero. Additionally, the value 0 is used to
+represent an *empty bitmask*, in which no bitmask elements are set.
 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.
 ##### Character sequences <a id="character.seq">[[character.seq]]</a>
 The C standard library makes widespread use of characters and character
 #### Headers <a id="headers">[[headers]]</a>
 Each element of the C++standard library is declared or defined (as
 appropriate) in a *header*.[^16]
+The C++standard library provides 53 *C++library headers*, as shown in
 Table  [[tab:cpp.library.headers]].
 **Table: C++library headers** <a id="tab:cpp.library.headers">[tab:cpp.library.headers]</a>
 |                        |                      |             |                      |                   |
 current definition of `NDEBUG`.[^20]
 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 in that translation unit to any of the entities
+declared in that header. No diagnostic is required.
 #### Linkage <a id="using.linkage">[[using.linkage]]</a>
 Entities in the C++standard library have external linkage (
 [[basic.link]]). Unless otherwise specified, objects and functions have
 **Table: `Destructible` requirements** <a id="destructible">[destructible]</a>
 |          |                                                                       |
+| -------- | --------------------------------------------------------------------- |
+| `u.~T()` | All resources owned by `u` are reclaimed, no exception is propagated. |
+#### `Swappable` requirements <a id="swappable.requirements">[[swappable.requirements]]</a>
 This subclause provides definitions for swappable types and expressions.
 In these definitions, let `t` denote an expression of type `T`, and let
 `u` denote an expression of type `U`.
 An rvalue or lvalue `t` is *swappable* if and only if `t` is swappable
 with any rvalue or lvalue, respectively, of type `T`.
 A type `X` satisfying any of the iterator requirements (
+[[iterator.requirements]]) satisfies the requirements of
+`ValueSwappable` if, for any dereferenceable object `x` of type `X`,
+`*x` is swappable.
 User code can ensure that the evaluation of `swap` calls is performed in
 an appropriate context under the various conditions as follows:
 ``` cpp
 (possibly `const`) `Key`.
 **Table: `Hash` requirements** <a id="hash">[hash]</a>
 |        |          |                                                                                                                                                                                                                                                                                                                                                                                                                                                   |
+| ------ | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `h(k)` | `size_t` | The value returned shall depend only on the argument `k` for the duration of the program. \enternote Thus all evaluations of the expression `h(k)` with the same value for `k` yield the same result for a given execution of the program. \exitnote \enternote For two different values `t1` and `t2`, the probability that `h(t1)` and `h(t2)` compare equal should be very small, approaching `1.0 / numeric_limits<size_t>::max()`. \exitnote |
 | `h(u)` | `size_t` | Shall not modify `u`.                                                                                                                                                                                                                                                                                                                                                                                                                             |
 #### Allocator requirements <a id="allocator.requirements">[[allocator.requirements]]</a>
 `rebind` member template, the standard `allocator_traits` template uses
 `SomeAllocator<U, Args>` in place of `Allocator::{}rebind<U>::other` by
 default. For allocator types that are not template instantiations of the
 above form, no default is provided.
+An allocator type `X` shall satisfy the requirements of
+`CopyConstructible` ([[utility.arg.requirements]]). The `X::pointer`,
+`X::const_pointer`, `X::void_pointer`, and `X::const_void_pointer` types
+shall satisfy the requirements of `NullablePointer` (
+[[nullablepointer.requirements]]). No constructor, comparison operator,
+copy operation, move operation, or swap operation on these types shall
+exit via an exception. `X::pointer` and `X::const_pointer` shall also
+satisfy the requirements for a random access iterator (
+[[iterator.requirements]]).
+Let `x1` and `x2` denote objects of (possibly different) types
+`X::void_pointer`, `X::const_void_pointer`, `X::pointer`, or
+`X::const_pointer`. Then, `x1` and `x2` are *equivalently-valued*
+pointer values, if and only if both `x1` and `x2` can be explicitly
+converted to the two corresponding objects `px1` and `px2` of type
+`X::const_pointer`, using a sequence of `static_cast`s using only these
+four types, and the expression `px1 == px2` evaluates to `true`.
+Let `w1` and `w2` denote objects of type `X::void_pointer`. Then for the
+expressions
+``` cpp
+w1 == w2
+w1 != w2
+```
+either or both objects may be replaced by an equivalently-valued object
+of type `X::const_void_pointer` with no change in semantics.
+Let `p1` and `p2` denote objects of type `X::pointer`. Then for the
+expressions
+``` cpp
+p1 == p2
+p1 != p2
+p1 < p2
+p1 <= p2
+p1 >= p2
+p1 > p2
+p1 - p2
+```
+either or both objects may be replaced by an equivalently-valued object
+of type `X::const_pointer` with no change in semantics.
 An allocator may constrain the types on which it can be instantiated and
 the arguments for which its `construct` member may be called. If a type
 cannot be used with a particular allocator, the allocator class or the
 call to `construct` may fail to instantiate.
   template <class T> SimpleAllocator(const SimpleAllocator<T>& other);
   Tp* allocate(std::size_t n);
   void deallocate(Tp* p, std::size_t n);
 };
+template <class T, class U>
+bool operator==(const SimpleAllocator<T>&, const SimpleAllocator<U>&);
+template <class T, class U>
+bool operator!=(const SimpleAllocator<T>&, const SimpleAllocator<U>&);
 ```
 If the alignment associated with a specific over-aligned type is not
 supported by an allocator, instantiation of the allocator for that type
 may fail. The allocator also may silently ignore the requested
 describe the behavior of numerous functions defined by the C++standard
 library. Under some circumstances, however, certain of these function
 descriptions also apply to replacement functions defined in the
 program ([[definitions]]).
+A C++program may provide the definition for any of twelve dynamic memory
 allocation function signatures declared in header `<new>` (
 [[basic.stc.dynamic]], [[support.dynamic]]):
 - `operator new(std::size_t)`
 - `operator new(std::size_t, const std::nothrow_t&)`
 - `operator new[](std::size_t, const std::nothrow_t&)`
 - `operator delete(void*)`
 - `operator delete(void*, const std::nothrow_t&)`
 - `operator delete[](void*)`
 - `operator delete[](void*, const std::nothrow_t&)`
+- `operator delete(void*, std::size_t)`
+- `operator delete(void*, std::size_t, const std::nothrow_t&)`
+- `operator delete[](void*, std::size_t)`
+- `operator delete[](void*, std::size_t, const std::nothrow_t&)`
 The program’s definitions are used instead of the default versions
 supplied by the implementation ([[support.dynamic]]). Such replacement
 occurs prior to program startup ([[basic.def.odr]], [[basic.start]]).
 The program’s definitions shall not be specified as `inline`. No
 Unless otherwise specified, global and non-member functions in the
 standard library shall not use functions from another namespace which
 are found through *argument-dependent name lookup* (
 [[basic.lookup.argdep]]). The phrase “unless otherwise specified” is
 intended to allow argument-dependent lookup in cases like that of
+`ostream_iterator::operator=` ([[ostream.iterator.ops]]):
+*Effects:*
 ``` cpp
 *out_stream << value;
 if (delim != 0)
   *out_stream << delim;
+return *this;
 ```
 #### Member functions <a id="member.functions">[[member.functions]]</a>
 It is unspecified whether any member functions in the C++standard
 library behaves as if the implementation declares no additional member
 function signatures.[^29]
 #### `constexpr` functions and constructors <a id="constexpr.functions">[[constexpr.functions]]</a>
+This standard explicitly requires that certain standard library
+functions are `constexpr` ([[dcl.constexpr]]). An implementation shall
+not declare any standard library function signature as `constexpr`
+except for those where it is explicitly required. Within any header that
+provides any non-defining declarations of `constexpr` functions or
+constructors an implementation shall provide corresponding definitions.
 #### Requirements for stable algorithms <a id="algorithm.stable">[[algorithm.stable]]</a>
 When the requirements for an algorithm state that it is “stable” without
 further elaboration, it means:
 - For the *sort* algorithms the relative order of equivalent elements is
   preserved.
+- For the *remove* and *copy* algorithms the relative order of the
+ elements that are not removed is preserved.
 - For the *merge* algorithms, for equivalent elements in the original
+  two ranges, the elements from the first range (preserving their
+ original order) precede the elements from the second range (preserving
+  their original order).
 #### Reentrancy <a id="reentrancy">[[reentrancy]]</a>
 Except where explicitly specified in this standard, it is
 *implementation-defined* which functions in the Standard C++ library may
 [conventions]: #conventions
 [cpp.include]: cpp.md#cpp.include
 [cstdint]: language.md#cstdint
 [dcl.array]: dcl.md#dcl.array
 [dcl.attr]: dcl.md#dcl.attr
+[dcl.constexpr]: dcl.md#dcl.constexpr
 [dcl.fct.default]: dcl.md#dcl.fct.default
 [dcl.fct.spec]: dcl.md#dcl.fct.spec
 [dcl.init]: dcl.md#dcl.init
 [dcl.link]: dcl.md#dcl.link
 [definitions]: #definitions
 [nullablepointer.requirements]: #nullablepointer.requirements
 [numeric.requirements]: numerics.md#numeric.requirements
 [numerics]: numerics.md#numerics
 [objects.within.classes]: #objects.within.classes
 [organization]: #organization
+[ostream.iterator.ops]: iterators.md#ostream.iterator.ops
 [over.match]: over.md#over.match
 [over.oper]: over.md#over.oper
 [protection.within.classes]: #protection.within.classes
 [re]: re.md#re
 [reentrancy]: #reentrancy
 [^20]: This is the same as the Standard C library.
 [^21]: The only reliable way to declare an object or function signature
     from the Standard C library is by including the header that declares
+    it, notwithstanding the latitude granted in 7.1.4 of the C Standard.
 [^22]: Any library code that instantiates other library templates must
     be prepared to work adequately with any user-supplied specialization
     that meets the minimum requirements of the Standard.

Diff to HTML by rtfpessoa