[allocator.requirements] - C++14 → C++17

Files changed (1) hide show

tmp/tmp7n_w3ez4/{from.md → to.md} +56 -23

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

@@ -8,12 +8,12 @@ this allocation model, as well as the memory allocation and deallocation
 primitives for it. All of the string types (Clause  [[strings]]),
 containers (Clause  [[containers]]) (except array), string buffers and
 string streams (Clause  [[input.output]]), and `match_results` (Clause
 [[re]]) are parameterized in terms of allocators.
-The template struct `allocator_traits` ([[allocator.traits]]) supplies
-a uniform interface to all allocator types. Table  [[tab:desc.var.def]]
 describes the types manipulated through allocators. Table
 [[tab:utilities.allocator.requirements]] describes the requirements on
 allocator types and thus on types used to instantiate
 `allocator_traits`. A requirement is optional if the last column of
 Table  [[tab:utilities.allocator.requirements]] specifies a default for
@@ -24,31 +24,47 @@ of `allocator_traits` may provide different defaults and may provide
 defaults for different requirements than the primary template. Within
 Tables  [[tab:desc.var.def]] and
 [[tab:utilities.allocator.requirements]], the use of `move` and
 `forward` always refers to `std::move` and `std::forward`, respectively.
 Note A: The member class template `rebind` in the table above is
-effectively a typedef template. In general, if the name `Allocator` is
-bound to `SomeAllocator<T>`, then `Allocator::rebind<U>::other` is the
-same type as `SomeAllocator<U>`, where `SomeAllocator<T>::value_type` is
-`T` and `SomeAllocator<U>::{}value_type` is `U`. If `Allocator` is a
-class template instantiation of the form `SomeAllocator<T, Args>`, where
-`Args` is zero or more type arguments, and `Allocator` does not supply 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
@@ -82,15 +98,18 @@ 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.
-the following is an allocator class template supporting the minimal
 interface that satisfies the requirements of Table
 [[tab:utilities.allocator.requirements]]:
 ``` cpp
 template <class Tp>
@@ -108,11 +127,25 @@ 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
-alignment. Additionally, the member function `allocate` for that type
-may fail by throwing an object of type `std::bad_alloc`.

 primitives for it. All of the string types (Clause  [[strings]]),
 containers (Clause  [[containers]]) (except array), string buffers and
 string streams (Clause  [[input.output]]), and `match_results` (Clause
 [[re]]) are parameterized in terms of allocators.
+The class template `allocator_traits` ([[allocator.traits]]) supplies a
+uniform interface to all allocator types. Table  [[tab:desc.var.def]]
 describes the types manipulated through allocators. Table
 [[tab:utilities.allocator.requirements]] describes the requirements on
 allocator types and thus on types used to instantiate
 `allocator_traits`. A requirement is optional if the last column of
 Table  [[tab:utilities.allocator.requirements]] specifies a default for
 defaults for different requirements than the primary template. Within
 Tables  [[tab:desc.var.def]] and
 [[tab:utilities.allocator.requirements]], the use of `move` and
 `forward` always refers to `std::move` and `std::forward`, respectively.
+[*Note 1*: If `n == 0`, the return value is unspecified. — *end note*]
 Note A: The member class template `rebind` in the table above is
+effectively a typedef template.
+[*Note 2*: In general, if the name `Allocator` is bound to
+`SomeAllocator<T>`, then `Allocator::rebind<U>::other` is the same type
+as `SomeAllocator<U>`, where `SomeAllocator<T>::value_type` is `T` and
+`SomeAllocator<U>::{}value_type` is `U`. — *end note*]
+If `Allocator` is a class template instantiation of the form
+`SomeAllocator<T, Args>`, where `Args` is zero or more type arguments,
+and `Allocator` does not supply 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.
+Note B: If `X::propagate_on_container_copy_assignment::value` is `true`,
+`X` shall satisfy the `CopyAssignable` requirements (Table
+[[tab:copyassignable]]) and the copy operation shall not throw
+exceptions. If `X::propagate_on_container_move_assignment::value` is
+`true`, `X` shall satisfy the `MoveAssignable` requirements (Table
+[[tab:moveassignable]]) and the move operation shall not throw
+exceptions. If `X::propagate_on_container_swap::value` is `true`,
+lvalues of type `X` shall be swappable ([[swappable.requirements]]) and
+the `swap` operation shall not throw exceptions.
 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 function,
+copy operation, move operation, or swap operation on these pointer types
+shall exit via an exception. `X::pointer` and `X::const_pointer` shall
+also satisfy the requirements for a random access iterator (
+[[random.access.iterators]]) and of a contiguous iterator (
+[[iterator.requirements.general]]).
 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
 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` or `destroy` members may be
+called. If a type cannot be used with a particular allocator, the
+allocator class or the call to `construct` or `destroy` may fail to
+instantiate.
+[*Example 1*:
+The following is an allocator class template supporting the minimal
 interface that satisfies the requirements of Table
 [[tab:utilities.allocator.requirements]]:
 ``` cpp
 template <class Tp>
 bool operator==(const SimpleAllocator<T>&, const SimpleAllocator<U>&);
 template <class T, class U>
 bool operator!=(const SimpleAllocator<T>&, const SimpleAllocator<U>&);
 ```
+— *end example*]
 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
+alignment.
+[*Note 3*: Additionally, the member function `allocate` for that type
+may fail by throwing an object of type `bad_alloc`. — *end note*]
+##### Allocator completeness requirements <a id="allocator.requirements.completeness">[[allocator.requirements.completeness]]</a>
+If `X` is an allocator class for type `T`, `X` additionally satisfies
+the allocator completeness requirements if, whether or not `T` is a
+complete type:
+- `X` is a complete type, and
+- all the member types of `allocator_traits<X>` ([[allocator.traits]])
+  other than `value_type` are complete types.

Diff to HTML by rtfpessoa