From Jason Turner

[utility.requirements]

C++14 → C++17 22.7 KB 212 lines
Current Draft | LaTeX Source
Archived: C++14 | C++17
Markdown: C++14 | C++17
Explore in Adventure Game

Diff to HTML by rtfpessoa

Files changed (1) hide show
  1. tmp/tmp28tdxrb0/{from.md → to.md} +115 -86
tmp/tmp28tdxrb0/{from.md → to.md} RENAMED
@@ -11,77 +11,71 @@ describes the requirements on hash function objects.
11
  allocators.
12
 
13
  #### Template argument requirements <a id="utility.arg.requirements">[[utility.arg.requirements]]</a>
14
 
15
  The template definitions in the C++standard library refer to various
16
- named requirements whose details are set out in tables 
17
- [[equalitycomparable]]– [[destructible]]. In these tables, `T` is an
18
- object or reference type to be supplied by a C++program instantiating a
19
- template; `a`, `b`, and `c` are values of type (possibly `const`) `T`;
20
- `s` and `t` are modifiable lvalues of type `T`; `u` denotes an
21
- identifier; `rv` is an rvalue of type `T`; and `v` is an lvalue of type
22
- (possibly `const`) `T` or an rvalue of type `const T`.
23
 
24
  In general, a default constructor is not required. Certain container
25
  class member function signatures specify `T()` as a default argument.
26
  `T()` shall be a well-defined expression ([[dcl.init]]) if one of those
27
  signatures is called using the default argument ([[dcl.fct.default]]).
28
 
29
  **Table: `EqualityComparable` requirements** <a id="equalitycomparable">[equalitycomparable]</a>
30
 
31
- | | | |
32
- | -------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
33
  | `a == b` | convertible to `bool` | `==` is an equivalence relation, that is, it has the following properties: For all `a`, `a == a`.; If `a == b`, then `b == a`.; If `a == b` and `b == c`, then `a == c`. |
34
 
35
  **Table: `LessThanComparable` requirements** <a id="lessthancomparable">[lessthancomparable]</a>
36
 
37
- | | | |
38
- | ------- | --------------------- | --------------------------------------------------------- |
39
  | `a < b` | convertible to `bool` | `<` is a strict weak ordering relation~([[alg.sorting]]) |
40
 
41
  **Table: `DefaultConstructible` requirements** <a id="defaultconstructible">[defaultconstructible]</a>
42
 
43
- | | |
44
- | -------- | --------------------------------------------------- |
45
  | `T t;` | object `t` is default-initialized |
46
- | `T u{};` | object `u` is value-initialized |
47
- | `T()` | a temporary object of type `T` is value-initialized |
48
- | `T{}` | |
49
 
50
- **Table: `MoveConstructible` requirements** <a id="moveconstructible">[moveconstructible]</a>
51
-
52
- | | |
53
- | ----------- | ------------------------------------------------------------------ |
54
- | `T u = rv;` | `u` is equivalent to the value of `rv` before the construction |
55
- | `T(rv)` | `T(rv)` is equivalent to the value of `rv` before the construction |
56
- | *[spans 2 columns]* `rv`'s state is unspecified \enternote `rv` must still meet the requirements of the library component that is using it. The operations listed in those requirements must work as specified whether `rv` has been moved from or not. \exitnote |
57
 
58
  **Table: `CopyConstructible` requirements (in addition to `MoveConstructible`)** <a id="copyconstructible">[copyconstructible]</a>
59
 
60
- | | |
61
  | ---------- | --------------------------------------------------------- |
62
  | `T u = v;` | the value of `v` is unchanged and is equivalent to ` u` |
63
  | `T(v)` | the value of `v` is unchanged and is equivalent to `T(v)` |
64
 
65
- **Table: `MoveAssignable` requirements** <a id="moveassignable">[moveassignable]</a>
66
-
67
- | | | | |
68
- | -------- | ---- | --- | ------------------------------------------------------------ |
69
- | `t = rv` | `T&` | `t` | `t` is equivalent to the value of `rv` before the assignment |
70
- | *[spans 4 columns]* `rv`'s state is unspecified. \enternote\ `rv` must still meet the requirements of the library component that is using it. The operations listed in those requirements must work as specified whether `rv` has been moved from or not. \exitnote |
71
 
72
  **Table: `CopyAssignable` requirements (in addition to `MoveAssignable`)** <a id="copyassignable">[copyassignable]</a>
73
 
74
- | | | | |
75
- | ------- | ---- | --- | ------------------------------------------------------- |
76
  | `t = v` | `T&` | `t` | `t` is equivalent to `v`, the value of `v` is unchanged |
77
 
78
 
79
  **Table: `Destructible` requirements** <a id="destructible">[destructible]</a>
80
 
81
- | | |
82
- | -------- | --------------------------------------------------------------------- |
83
  | `u.~T()` | All resources owned by `u` are reclaimed, no exception is propagated. |
84
 
85
 
86
  #### `Swappable` requirements <a id="swappable.requirements">[[swappable.requirements]]</a>
87
 
@@ -105,28 +99,30 @@ overload resolution ([[over.match]]) on a candidate set that includes:
105
  - the two `swap` function templates defined in `<utility>` (
106
  [[utility]]) and
107
  - the lookup set produced by argument-dependent lookup (
108
  [[basic.lookup.argdep]]).
109
 
110
- If `T` and `U` are both fundamental types or arrays of fundamental types
111
- and the declarations from the header `<utility>` are in scope, the
112
- overall lookup set described above is equivalent to that of the
113
- qualified name lookup applied to the expression `std::swap(t, u)` or
114
- `std::swap(u, t)` as appropriate.
115
 
116
- It is unspecified whether a library component that has a swappable
117
- requirement includes the header `<utility>` to ensure an appropriate
118
- evaluation context.
119
 
120
  An rvalue or lvalue `t` is *swappable* if and only if `t` is swappable
121
  with any rvalue or lvalue, respectively, of type `T`.
122
 
123
  A type `X` satisfying any of the iterator requirements (
124
  [[iterator.requirements]]) satisfies the requirements of
125
  `ValueSwappable` if, for any dereferenceable object `x` of type `X`,
126
  `*x` is swappable.
127
 
 
 
128
  User code can ensure that the evaluation of `swap` calls is performed in
129
  an appropriate context under the various conditions as follows:
130
 
131
  ``` cpp
132
  #include <utility>
@@ -139,11 +135,11 @@ void value_swap(T&& t, U&& u) {
139
  // for rvalues and lvalues
140
  }
141
 
142
  // Requires: lvalues of T shall be swappable.
143
  template <class T>
144
- void lv_swap(T& t1 T& t2) {
145
  using std::swap;
146
  swap(t1, t2); // OK: uses swappable conditions for
147
  } // lvalues of type T
148
 
149
  namespace N {
@@ -167,48 +163,52 @@ int main() {
167
  value_swap(a1, proxy(a2));
168
  assert(a1.m == -5 && a2.m == 5);
169
  }
170
  ```
171
 
 
 
172
  #### `NullablePointer` requirements <a id="nullablepointer.requirements">[[nullablepointer.requirements]]</a>
173
 
174
  A `NullablePointer` type is a pointer-like type that supports null
175
  values. A type `P` meets the requirements of `NullablePointer` if:
176
 
177
  - `P` satisfies the requirements of `EqualityComparable`,
178
  `DefaultConstructible`, `CopyConstructible`, `CopyAssignable`, and
179
  `Destructible`,
180
  - lvalues of type `P` are swappable ([[swappable.requirements]]),
181
- - the expressions shown in Table  [[nullablepointer]] are valid and have
182
- the indicated semantics, and
183
  - `P` satisfies all the other requirements of this subclause.
184
 
185
  A value-initialized object of type `P` produces the null value of the
186
  type. The null value shall be equivalent only to itself. A
187
  default-initialized object of type `P` may have an indeterminate value.
188
- Operations involving indeterminate values may cause undefined behavior.
 
 
189
 
190
  An object `p` of type `P` can be contextually converted to `bool`
191
  (Clause  [[conv]]). The effect shall be as if `p != nullptr` had been
192
  evaluated in place of `p`.
193
 
194
  No operation which is part of the `NullablePointer` requirements shall
195
  exit via an exception.
196
 
197
- In Table  [[nullablepointer]], `u` denotes an identifier, `t` denotes a
198
- non-`const` lvalue of type `P`, `a` and `b` denote values of type
199
- (possibly `const`) `P`, and `np` denotes a value of type (possibly
200
  `const`) `std::nullptr_t`.
201
 
202
  **Table: `NullablePointer` requirements** <a id="nullablepointer">[nullablepointer]</a>
203
 
204
  | | | |
205
- | -------------- | ---------------------------------- | ------------------------ |
206
- | `P u(np);`<br> | | post: `u == nullptr` |
207
  | `P u = np;` | | |
208
- | `P(np)` | | post: `P(np) == nullptr` |
209
- | `t = np` | `P&` | post: `t == nullptr` |
210
  | `a != b` | contextually convertible to `bool` | `!(a == b)` |
211
  | `a == np` | contextually convertible to `bool` | `a == P()` |
212
  | `np == a` | | |
213
  | `a != np` | contextually convertible to `bool` | `!(a == np)` |
214
  | `np != a` | | |
@@ -219,25 +219,21 @@ non-`const` lvalue of type `P`, `a` and `b` denote values of type
219
  A type `H` meets the `Hash` requirements if:
220
 
221
  - it is a function object type ([[function.objects]]),
222
  - it satisfies the requirements of `CopyConstructible` and
223
  `Destructible` ([[utility.arg.requirements]]), and
224
- - the expressions shown in Table  [[hash]] are valid and have the
225
  indicated semantics.
226
 
227
  Given `Key` is an argument type for function objects of type `H`, in
228
- Table  [[hash]] `h` is a value of type (possibly `const`) `H`, `u` is an
229
- lvalue of type `Key`, and `k` is a value of a type convertible to
230
  (possibly `const`) `Key`.
231
 
232
- **Table: `Hash` requirements** <a id="hash">[hash]</a>
233
-
234
- | | | |
235
- | ------ | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
236
- | `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 |
237
- | `h(u)` | `size_t` | Shall not modify `u`. |
238
-
239
 
240
  #### Allocator requirements <a id="allocator.requirements">[[allocator.requirements]]</a>
241
 
242
  The library describes a standard set of requirements for *allocators*,
243
  which are class-type objects that encapsulate the information about an
@@ -247,12 +243,12 @@ this allocation model, as well as the memory allocation and deallocation
247
  primitives for it. All of the string types (Clause  [[strings]]),
248
  containers (Clause  [[containers]]) (except array), string buffers and
249
  string streams (Clause  [[input.output]]), and `match_results` (Clause 
250
  [[re]]) are parameterized in terms of allocators.
251
 
252
- The template struct `allocator_traits` ([[allocator.traits]]) supplies
253
- a uniform interface to all allocator types. Table  [[tab:desc.var.def]]
254
  describes the types manipulated through allocators. Table 
255
  [[tab:utilities.allocator.requirements]] describes the requirements on
256
  allocator types and thus on types used to instantiate
257
  `allocator_traits`. A requirement is optional if the last column of
258
  Table  [[tab:utilities.allocator.requirements]] specifies a default for
@@ -263,31 +259,47 @@ of `allocator_traits` may provide different defaults and may provide
263
  defaults for different requirements than the primary template. Within
264
  Tables  [[tab:desc.var.def]] and 
265
  [[tab:utilities.allocator.requirements]], the use of `move` and
266
  `forward` always refers to `std::move` and `std::forward`, respectively.
267
 
 
 
268
  Note A: The member class template `rebind` in the table above is
269
- effectively a typedef template. In general, if the name `Allocator` is
270
- bound to `SomeAllocator<T>`, then `Allocator::rebind<U>::other` is the
271
- same type as `SomeAllocator<U>`, where `SomeAllocator<T>::value_type` is
272
- `T` and `SomeAllocator<U>::{}value_type` is `U`. If `Allocator` is a
273
- class template instantiation of the form `SomeAllocator<T, Args>`, where
274
- `Args` is zero or more type arguments, and `Allocator` does not supply a
275
- `rebind` member template, the standard `allocator_traits` template uses
276
- `SomeAllocator<U, Args>` in place of `Allocator::{}rebind<U>::other` by
277
- default. For allocator types that are not template instantiations of the
278
- above form, no default is provided.
 
 
 
 
 
 
 
 
 
 
 
 
 
279
 
280
  An allocator type `X` shall satisfy the requirements of
281
  `CopyConstructible` ([[utility.arg.requirements]]). The `X::pointer`,
282
  `X::const_pointer`, `X::void_pointer`, and `X::const_void_pointer` types
283
  shall satisfy the requirements of `NullablePointer` (
284
- [[nullablepointer.requirements]]). No constructor, comparison operator,
285
- copy operation, move operation, or swap operation on these types shall
286
- exit via an exception. `X::pointer` and `X::const_pointer` shall also
287
- satisfy the requirements for a random access iterator (
288
- [[iterator.requirements]]).
 
289
 
290
  Let `x1` and `x2` denote objects of (possibly different) types
291
  `X::void_pointer`, `X::const_void_pointer`, `X::pointer`, or
292
  `X::const_pointer`. Then, `x1` and `x2` are *equivalently-valued*
293
  pointer values, if and only if both `x1` and `x2` can be explicitly
@@ -321,15 +333,18 @@ p1 - p2
321
 
322
  either or both objects may be replaced by an equivalently-valued object
323
  of type `X::const_pointer` with no change in semantics.
324
 
325
  An allocator may constrain the types on which it can be instantiated and
326
- the arguments for which its `construct` member may be called. If a type
327
- cannot be used with a particular allocator, the allocator class or the
328
- call to `construct` may fail to instantiate.
 
329
 
330
- the following is an allocator class template supporting the minimal
 
 
331
  interface that satisfies the requirements of Table 
332
  [[tab:utilities.allocator.requirements]]:
333
 
334
  ``` cpp
335
  template <class Tp>
@@ -347,11 +362,25 @@ template <class T, class U>
347
  bool operator==(const SimpleAllocator<T>&, const SimpleAllocator<U>&);
348
  template <class T, class U>
349
  bool operator!=(const SimpleAllocator<T>&, const SimpleAllocator<U>&);
350
  ```
351
 
 
 
352
  If the alignment associated with a specific over-aligned type is not
353
  supported by an allocator, instantiation of the allocator for that type
354
  may fail. The allocator also may silently ignore the requested
355
- alignment. Additionally, the member function `allocate` for that type
356
- may fail by throwing an object of type `std::bad_alloc`.
 
 
 
 
 
 
 
 
 
 
 
 
357
 
 
11
  allocators.
12
 
13
  #### Template argument requirements <a id="utility.arg.requirements">[[utility.arg.requirements]]</a>
14
 
15
  The template definitions in the C++standard library refer to various
16
+ named requirements whose details are set out in Tables 
17
+ [[tab:equalitycomparable]]– [[tab:destructible]]. In these tables, `T`
18
+ is an object or reference type to be supplied by a C++program
19
+ instantiating a template; `a`, `b`, and `c` are values of type (possibly
20
+ `const`) `T`; `s` and `t` are modifiable lvalues of type `T`; `u`
21
+ denotes an identifier; `rv` is an rvalue of type `T`; and `v` is an
22
+ lvalue of type (possibly `const`) `T` or an rvalue of type `const T`.
23
 
24
  In general, a default constructor is not required. Certain container
25
  class member function signatures specify `T()` as a default argument.
26
  `T()` shall be a well-defined expression ([[dcl.init]]) if one of those
27
  signatures is called using the default argument ([[dcl.fct.default]]).
28
 
29
  **Table: `EqualityComparable` requirements** <a id="equalitycomparable">[equalitycomparable]</a>
30
 
31
+ | Expression | Return type |
32
+ | ---------- | ----------- |
33
  | `a == b` | convertible to `bool` | `==` is an equivalence relation, that is, it has the following properties: For all `a`, `a == a`.; If `a == b`, then `b == a`.; If `a == b` and `b == c`, then `a == c`. |
34
 
35
  **Table: `LessThanComparable` requirements** <a id="lessthancomparable">[lessthancomparable]</a>
36
 
37
+ | Expression | Return type | Requirement |
38
+ | ---------- | --------------------- | --------------------------------------------------------- |
39
  | `a < b` | convertible to `bool` | `<` is a strict weak ordering relation~([[alg.sorting]]) |
40
 
41
  **Table: `DefaultConstructible` requirements** <a id="defaultconstructible">[defaultconstructible]</a>
42
 
43
+ | Expression | Post-condition |
44
+ | -------------- | ------------------------------------------------------------------- |
45
  | `T t;` | object `t` is default-initialized |
46
+ | `T u{};` | object `u` is value-initialized or aggregate-initialized |
47
+ | `T()`<br>`T{}` | an object of type `T` is value-initialized or aggregate-initialized |
 
48
 
49
+ [*Note 1*: `rv` must still meet the requirements of the library
50
+ component that is using it. The operations listed in those requirements
51
+ must work as specified whether `rv` has been moved from or
52
+ not. — *end note*]
 
 
 
53
 
54
  **Table: `CopyConstructible` requirements (in addition to `MoveConstructible`)** <a id="copyconstructible">[copyconstructible]</a>
55
 
56
+ | Expression | Post-condition |
57
  | ---------- | --------------------------------------------------------- |
58
  | `T u = v;` | the value of `v` is unchanged and is equivalent to ` u` |
59
  | `T(v)` | the value of `v` is unchanged and is equivalent to `T(v)` |
60
 
61
+ [*Note 2*:  `rv` must still meet the requirements of the library
62
+ component that is using it, whether or not `t` and `rv` refer to the
63
+ same object. The operations listed in those requirements must work as
64
+ specified whether `rv` has been moved from or not. — *end note*]
 
 
65
 
66
  **Table: `CopyAssignable` requirements (in addition to `MoveAssignable`)** <a id="copyassignable">[copyassignable]</a>
67
 
68
+ | Expression | Return type | Return value | Post-condition |
69
+ | ---------- | ----------- | ------------ | ------------------------------------------------------- |
70
  | `t = v` | `T&` | `t` | `t` is equivalent to `v`, the value of `v` is unchanged |
71
 
72
 
73
  **Table: `Destructible` requirements** <a id="destructible">[destructible]</a>
74
 
75
+ | Expression | Post-condition |
76
+ | ---------- | --------------------------------------------------------------------- |
77
  | `u.~T()` | All resources owned by `u` are reclaimed, no exception is propagated. |
78
 
79
 
80
  #### `Swappable` requirements <a id="swappable.requirements">[[swappable.requirements]]</a>
81
 
 
99
  - the two `swap` function templates defined in `<utility>` (
100
  [[utility]]) and
101
  - the lookup set produced by argument-dependent lookup (
102
  [[basic.lookup.argdep]]).
103
 
104
+ [*Note 1*: If `T` and `U` are both fundamental types or arrays of
105
+ fundamental types and the declarations from the header `<utility>` are
106
+ in scope, the overall lookup set described above is equivalent to that
107
+ of the qualified name lookup applied to the expression `std::swap(t, u)`
108
+ or `std::swap(u, t)` as appropriate. — *end note*]
109
 
110
+ [*Note 2*: It is unspecified whether a library component that has a
111
+ swappable requirement includes the header `<utility>` to ensure an
112
+ appropriate evaluation context. — *end note*]
113
 
114
  An rvalue or lvalue `t` is *swappable* if and only if `t` is swappable
115
  with any rvalue or lvalue, respectively, of type `T`.
116
 
117
  A type `X` satisfying any of the iterator requirements (
118
  [[iterator.requirements]]) satisfies the requirements of
119
  `ValueSwappable` if, for any dereferenceable object `x` of type `X`,
120
  `*x` is swappable.
121
 
122
+ [*Example 1*:
123
+
124
  User code can ensure that the evaluation of `swap` calls is performed in
125
  an appropriate context under the various conditions as follows:
126
 
127
  ``` cpp
128
  #include <utility>
 
135
  // for rvalues and lvalues
136
  }
137
 
138
  // Requires: lvalues of T shall be swappable.
139
  template <class T>
140
+ void lv_swap(T& t1, T& t2) {
141
  using std::swap;
142
  swap(t1, t2); // OK: uses swappable conditions for
143
  } // lvalues of type T
144
 
145
  namespace N {
 
163
  value_swap(a1, proxy(a2));
164
  assert(a1.m == -5 && a2.m == 5);
165
  }
166
  ```
167
 
168
+ — *end example*]
169
+
170
  #### `NullablePointer` requirements <a id="nullablepointer.requirements">[[nullablepointer.requirements]]</a>
171
 
172
  A `NullablePointer` type is a pointer-like type that supports null
173
  values. A type `P` meets the requirements of `NullablePointer` if:
174
 
175
  - `P` satisfies the requirements of `EqualityComparable`,
176
  `DefaultConstructible`, `CopyConstructible`, `CopyAssignable`, and
177
  `Destructible`,
178
  - lvalues of type `P` are swappable ([[swappable.requirements]]),
179
+ - the expressions shown in Table  [[tab:nullablepointer]] are valid and
180
+ have the indicated semantics, and
181
  - `P` satisfies all the other requirements of this subclause.
182
 
183
  A value-initialized object of type `P` produces the null value of the
184
  type. The null value shall be equivalent only to itself. A
185
  default-initialized object of type `P` may have an indeterminate value.
186
+
187
+ [*Note 1*: Operations involving indeterminate values may cause
188
+ undefined behavior. — *end note*]
189
 
190
  An object `p` of type `P` can be contextually converted to `bool`
191
  (Clause  [[conv]]). The effect shall be as if `p != nullptr` had been
192
  evaluated in place of `p`.
193
 
194
  No operation which is part of the `NullablePointer` requirements shall
195
  exit via an exception.
196
 
197
+ In Table  [[tab:nullablepointer]], `u` denotes an identifier, `t`
198
+ denotes a non-`const` lvalue of type `P`, `a` and `b` denote values of
199
+ type (possibly `const`) `P`, and `np` denotes a value of type (possibly
200
  `const`) `std::nullptr_t`.
201
 
202
  **Table: `NullablePointer` requirements** <a id="nullablepointer">[nullablepointer]</a>
203
 
204
  | | | |
205
+ | -------------- | ---------------------------------- | ---------------------------------- |
206
+ | `P u(np);`<br> | | Postconditions: `u == nullptr` |
207
  | `P u = np;` | | |
208
+ | `P(np)` | | Postconditions: `P(np) == nullptr` |
209
+ | `t = np` | `P&` | Postconditions: `t == nullptr` |
210
  | `a != b` | contextually convertible to `bool` | `!(a == b)` |
211
  | `a == np` | contextually convertible to `bool` | `a == P()` |
212
  | `np == a` | | |
213
  | `a != np` | contextually convertible to `bool` | `!(a == np)` |
214
  | `np != a` | | |
 
219
  A type `H` meets the `Hash` requirements if:
220
 
221
  - it is a function object type ([[function.objects]]),
222
  - it satisfies the requirements of `CopyConstructible` and
223
  `Destructible` ([[utility.arg.requirements]]), and
224
+ - the expressions shown in Table  [[tab:hash]] are valid and have the
225
  indicated semantics.
226
 
227
  Given `Key` is an argument type for function objects of type `H`, in
228
+ Table  [[tab:hash]] `h` is a value of type (possibly `const`) `H`, `u`
229
+ is an lvalue of type `Key`, and `k` is a value of a type convertible to
230
  (possibly `const`) `Key`.
231
 
232
+ [*Note 1*: Thus all evaluations of the expression `h(k)` with the same
233
+ value for `k` yield the same result for a given execution of the
234
+ program. — *end note*]
 
 
 
 
235
 
236
  #### Allocator requirements <a id="allocator.requirements">[[allocator.requirements]]</a>
237
 
238
  The library describes a standard set of requirements for *allocators*,
239
  which are class-type objects that encapsulate the information about an
 
243
  primitives for it. All of the string types (Clause  [[strings]]),
244
  containers (Clause  [[containers]]) (except array), string buffers and
245
  string streams (Clause  [[input.output]]), and `match_results` (Clause 
246
  [[re]]) are parameterized in terms of allocators.
247
 
248
+ The class template `allocator_traits` ([[allocator.traits]]) supplies a
249
+ uniform interface to all allocator types. Table  [[tab:desc.var.def]]
250
  describes the types manipulated through allocators. Table 
251
  [[tab:utilities.allocator.requirements]] describes the requirements on
252
  allocator types and thus on types used to instantiate
253
  `allocator_traits`. A requirement is optional if the last column of
254
  Table  [[tab:utilities.allocator.requirements]] specifies a default for
 
259
  defaults for different requirements than the primary template. Within
260
  Tables  [[tab:desc.var.def]] and 
261
  [[tab:utilities.allocator.requirements]], the use of `move` and
262
  `forward` always refers to `std::move` and `std::forward`, respectively.
263
 
264
+ [*Note 1*: If `n == 0`, the return value is unspecified. — *end note*]
265
+
266
  Note A: The member class template `rebind` in the table above is
267
+ effectively a typedef template.
268
+
269
+ [*Note 2*: In general, if the name `Allocator` is bound to
270
+ `SomeAllocator<T>`, then `Allocator::rebind<U>::other` is the same type
271
+ as `SomeAllocator<U>`, where `SomeAllocator<T>::value_type` is `T` and
272
+ `SomeAllocator<U>::{}value_type` is `U`. — *end note*]
273
+
274
+ If `Allocator` is a class template instantiation of the form
275
+ `SomeAllocator<T, Args>`, where `Args` is zero or more type arguments,
276
+ and `Allocator` does not supply a `rebind` member template, the standard
277
+ `allocator_traits` template uses `SomeAllocator<U, Args>` in place of
278
+ `Allocator::{}rebind<U>::other` by default. For allocator types that are
279
+ not template instantiations of the above form, no default is provided.
280
+
281
+ Note B: If `X::propagate_on_container_copy_assignment::value` is `true`,
282
+ `X` shall satisfy the `CopyAssignable` requirements (Table 
283
+ [[tab:copyassignable]]) and the copy operation shall not throw
284
+ exceptions. If `X::propagate_on_container_move_assignment::value` is
285
+ `true`, `X` shall satisfy the `MoveAssignable` requirements (Table 
286
+ [[tab:moveassignable]]) and the move operation shall not throw
287
+ exceptions. If `X::propagate_on_container_swap::value` is `true`,
288
+ lvalues of type `X` shall be swappable ([[swappable.requirements]]) and
289
+ the `swap` operation shall not throw exceptions.
290
 
291
  An allocator type `X` shall satisfy the requirements of
292
  `CopyConstructible` ([[utility.arg.requirements]]). The `X::pointer`,
293
  `X::const_pointer`, `X::void_pointer`, and `X::const_void_pointer` types
294
  shall satisfy the requirements of `NullablePointer` (
295
+ [[nullablepointer.requirements]]). No constructor, comparison function,
296
+ copy operation, move operation, or swap operation on these pointer types
297
+ shall exit via an exception. `X::pointer` and `X::const_pointer` shall
298
+ also satisfy the requirements for a random access iterator (
299
+ [[random.access.iterators]]) and of a contiguous iterator (
300
+ [[iterator.requirements.general]]).
301
 
302
  Let `x1` and `x2` denote objects of (possibly different) types
303
  `X::void_pointer`, `X::const_void_pointer`, `X::pointer`, or
304
  `X::const_pointer`. Then, `x1` and `x2` are *equivalently-valued*
305
  pointer values, if and only if both `x1` and `x2` can be explicitly
 
333
 
334
  either or both objects may be replaced by an equivalently-valued object
335
  of type `X::const_pointer` with no change in semantics.
336
 
337
  An allocator may constrain the types on which it can be instantiated and
338
+ the arguments for which its `construct` or `destroy` members may be
339
+ called. If a type cannot be used with a particular allocator, the
340
+ allocator class or the call to `construct` or `destroy` may fail to
341
+ instantiate.
342
 
343
+ [*Example 1*:
344
+
345
+ The following is an allocator class template supporting the minimal
346
  interface that satisfies the requirements of Table 
347
  [[tab:utilities.allocator.requirements]]:
348
 
349
  ``` cpp
350
  template <class Tp>
 
362
  bool operator==(const SimpleAllocator<T>&, const SimpleAllocator<U>&);
363
  template <class T, class U>
364
  bool operator!=(const SimpleAllocator<T>&, const SimpleAllocator<U>&);
365
  ```
366
 
367
+ — *end example*]
368
+
369
  If the alignment associated with a specific over-aligned type is not
370
  supported by an allocator, instantiation of the allocator for that type
371
  may fail. The allocator also may silently ignore the requested
372
+ alignment.
373
+
374
+ [*Note 3*: Additionally, the member function `allocate` for that type
375
+ may fail by throwing an object of type `bad_alloc`. — *end note*]
376
+
377
+ ##### Allocator completeness requirements <a id="allocator.requirements.completeness">[[allocator.requirements.completeness]]</a>
378
+
379
+ If `X` is an allocator class for type `T`, `X` additionally satisfies
380
+ the allocator completeness requirements if, whether or not `T` is a
381
+ complete type:
382
+
383
+ - `X` is a complete type, and
384
+ - all the member types of `allocator_traits<X>` ([[allocator.traits]])
385
+ other than `value_type` are complete types.
386