[container.requirements.general]

Files changed (1) hide show

tmp/tmpyk5opiu7/{from.md → to.md} +46 -43

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

@@ -14,31 +14,31 @@ linear complexity, even though the complexity of copying each contained
 For the components affected by this subclause that declare an
 `allocator_type`, objects stored in these components shall be
 constructed using the function
 `allocator_traits<allocator_type>::rebind_traits<U>::{}construct` and
 destroyed using the function
-`allocator_traits<allocator_type>::rebind_traits<U>::{}destroy` (
-[[allocator.traits.members]]), where `U` is either
 `allocator_type::value_type` or an internal type used by the container.
 These functions are called only for the container’s element type, not
 for internal types used by the container.
 [*Note 1*: This means, for example, that a node-based container might
 need to construct nodes containing aligned buffers and call `construct`
 to place the element into the buffer. — *end note*]
-In Tables  [[tab:containers.container.requirements]],
-[[tab:containers.reversible.requirements]], and
-[[tab:containers.optional.operations]] `X` denotes a container class
-containing objects of type `T`, `a` and `b` denote values of type `X`,
-`u` denotes an identifier, `r` denotes a non-const value of type `X`,
-and `rv` denotes a non-const rvalue of type `X`.
 Those entries marked “(Note A)” or “(Note B)” have linear complexity for
 `array` and have constant complexity for all other standard containers.
-[*Note 2*: The algorithm `equal()` is defined in Clause
 [[algorithms]]. — *end note*]
 The member function `size()` returns the number of elements in the
 container. The number of elements is defined by the rules of
 constructors, inserts, and erases.
@@ -56,10 +56,11 @@ i == j
 i != j
 i < j
 i <= j
 i >= j
 i > j
 i - j
 ```
 where `i` and `j` denote objects of a container’s `iterator` type,
 either or both may be replaced by an object of the container’s
@@ -83,11 +84,11 @@ constructors obtain an allocator by move construction from the allocator
 belonging to the container being moved. Such move construction of the
 allocator shall not exit via an exception. All other constructors for
 these container types take a `const allocator_type&` argument.
 [*Note 4*: If an invocation of a constructor uses the default value of
-an optional allocator argument, then the `Allocator` type must support
 value-initialization. — *end note*]
 A copy of this allocator is used for any memory allocation and element
 construction performed, by these constructors and by all member
 functions, during the lifetime of each container object or until the
@@ -121,13 +122,13 @@ element in one container before the swap shall refer to the same element
 in the other container after the swap. It is unspecified whether an
 iterator with value `a.end()` before the swap will have value `b.end()`
 after the swap.
 If the iterator type of a container belongs to the bidirectional or
-random access iterator categories ([[iterator.requirements]]), the
-container is called *reversible* and satisfies the additional
-requirements in Table  [[tab:containers.reversible.requirements]].
 Unless otherwise specified (see  [[associative.reqmts.except]],
 [[unord.req.except]], [[deque.modifiers]], and [[vector.modifiers]]) all
 container types defined in this Clause meet the following additional
 requirements:
@@ -151,38 +152,40 @@ Unless otherwise specified (either explicitly or by defining a function
 in terms of other functions), invoking a container member function or
 passing a container as an argument to a library function shall not
 invalidate iterators to, or change the values of, objects within that
 container.
-A *contiguous container* is a container that supports random access
-iterators ([[random.access.iterators]]) and whose member types
-`iterator` and `const_iterator` are contiguous iterators (
-[[iterator.requirements.general]]).
-Table  [[tab:containers.optional.operations]] lists operations that are
-provided for some types of containers but not others. Those containers
-for which the listed operations are provided shall implement the
-semantics described in Table  [[tab:containers.optional.operations]]
-unless otherwise stated.
-[*Note 6*: The algorithm `lexicographical_compare()` is defined in
-Clause  [[algorithms]]. — *end note*]
 All of the containers defined in this Clause and in  [[basic.string]]
 except `array` meet the additional requirements of an allocator-aware
-container, as described in Table  [[tab:containers.allocatoraware]].
 Given an allocator type `A` and given a container type `X` having a
 `value_type` identical to `T` and an `allocator_type` identical to
 `allocator_traits<A>::rebind_alloc<T>` and given an lvalue `m` of type
 `A`, a pointer `p` of type `T*`, an expression `v` of type (possibly
 `const`) `T`, and an rvalue `rv` of type `T`, the following terms are
 defined. If `X` is not allocator-aware, the terms below are defined as
 if `A` were `allocator<T>` — no allocator object needs to be created and
 user specializations of `allocator<T>` are not instantiated:
-- `T` is *`DefaultInsertable` into `X`* means that the following
   expression is well-formed:
   ``` cpp
   allocator_traits<A>::construct(m, p)
   ```
 - An element of `X` is *default-inserted* if it is initialized by
@@ -191,63 +194,63 @@ user specializations of `allocator<T>` are not instantiated:
   allocator_traits<A>::construct(m, p)
   ```
   where `p` is the address of the uninitialized storage for the element
   allocated within `X`.
-- `T` is *`MoveInsertable` into `X`* means that the following expression
-  is well-formed:
   ``` cpp
   allocator_traits<A>::construct(m, p, rv)
   ```
   and its evaluation causes the following postcondition to hold: The
   value of `*p` is equivalent to the value of `rv` before the
   evaluation.
   \[*Note 7*: `rv` remains a valid object. Its state is
   unspecified — *end note*]
-- `T` is *`CopyInsertable` into `X`* means that, in addition to `T`
-  being `MoveInsertable` into `X`, the following expression is
   well-formed:
   ``` cpp
   allocator_traits<A>::construct(m, p, v)
   ```
   and its evaluation causes the following postcondition to hold: The
   value of `v` is unchanged and is equivalent to `*p`.
-- `T` is *`EmplaceConstructible` into `X` from `args`*, for zero or more
-  arguments `args`, means that the following expression is well-formed:
   ``` cpp
   allocator_traits<A>::construct(m, p, args)
   ```
-- `T` is *`Erasable` from `X`* means that the following expression is
-  well-formed:
   ``` cpp
   allocator_traits<A>::destroy(m, p)
   ```
 [*Note 8*: A container calls
 `allocator_traits<A>::construct(m, p, args)` to construct an element at
 `p` using `args`, with `m == get_allocator()`. The default `construct`
 in `allocator` will call `::new((void*)p) T(args)`, but specialized
 allocators may choose a different definition. — *end note*]
-In Table  [[tab:containers.allocatoraware]], `X` denotes an
-allocator-aware container class with a `value_type` of `T` using
-allocator of type `A`, `u` denotes a variable, `a` and `b` denote
-non-const lvalues of type `X`, `t` denotes an lvalue or a const rvalue
-of type `X`, `rv` denotes a non-const rvalue of type `X`, and `m` is a
-value of type `A`.
 The behavior of certain container member functions and deduction guides
 depends on whether types qualify as input iterators or allocators. The
 extent to which an implementation determines that a type cannot be an
 input iterator is unspecified, except that as a minimum integral types
 shall not qualify as input iterators. Likewise, the extent to which an
 implementation determines that a type cannot be an allocator is
 unspecified, except that as a minimum a type `A` shall not qualify as an
-allocator unless it satisfies both of the following conditions:
-- The *qualified-id* `A::value_type` is valid and denotes a type (
-  [[temp.deduct]]).
 - The expression `declval<A&>().allocate(size_t{})` is well-formed when
   treated as an unevaluated operand.

 For the components affected by this subclause that declare an
 `allocator_type`, objects stored in these components shall be
 constructed using the function
 `allocator_traits<allocator_type>::rebind_traits<U>::{}construct` and
 destroyed using the function
+`allocator_traits<allocator_type>::rebind_traits<U>::{}destroy`
+[[allocator.traits.members]], where `U` is either
 `allocator_type::value_type` or an internal type used by the container.
 These functions are called only for the container’s element type, not
 for internal types used by the container.
 [*Note 1*: This means, for example, that a node-based container might
 need to construct nodes containing aligned buffers and call `construct`
 to place the element into the buffer. — *end note*]
+In Tables  [[tab:container.req]], [[tab:container.rev.req]], and
+[[tab:container.opt]] `X` denotes a container class containing objects
+of type `T`, `a` and `b` denote values of type `X`, `i` and `j` denote
+values of type (possibly const) `X::iterator`, `u` denotes an
+identifier, `r` denotes a non-const value of type `X`, and `rv` denotes
+a non-const rvalue of type `X`.
 Those entries marked “(Note A)” or “(Note B)” have linear complexity for
 `array` and have constant complexity for all other standard containers.
+[*Note 2*: The algorithm `equal()` is defined in
 [[algorithms]]. — *end note*]
 The member function `size()` returns the number of elements in the
 container. The number of elements is defined by the rules of
 constructors, inserts, and erases.
 i != j
 i < j
 i <= j
 i >= j
 i > j
+i <=> j
 i - j
 ```
 where `i` and `j` denote objects of a container’s `iterator` type,
 either or both may be replaced by an object of the container’s
 belonging to the container being moved. Such move construction of the
 allocator shall not exit via an exception. All other constructors for
 these container types take a `const allocator_type&` argument.
 [*Note 4*: If an invocation of a constructor uses the default value of
+an optional allocator argument, then the allocator type must support
 value-initialization. — *end note*]
 A copy of this allocator is used for any memory allocation and element
 construction performed, by these constructors and by all member
 functions, during the lifetime of each container object or until the
 in the other container after the swap. It is unspecified whether an
 iterator with value `a.end()` before the swap will have value `b.end()`
 after the swap.
 If the iterator type of a container belongs to the bidirectional or
+random access iterator categories [[iterator.requirements]], the
+container is called *reversible* and meets the additional requirements
+in [[container.rev.req]].
 Unless otherwise specified (see  [[associative.reqmts.except]],
 [[unord.req.except]], [[deque.modifiers]], and [[vector.modifiers]]) all
 container types defined in this Clause meet the following additional
 requirements:
 in terms of other functions), invoking a container member function or
 passing a container as an argument to a library function shall not
 invalidate iterators to, or change the values of, objects within that
 container.
+A *contiguous container* is a container whose member types `iterator`
+and `const_iterator` meet the *Cpp17RandomAccessIterator* requirements
+[[random.access.iterators]] and model `contiguous_iterator`
+[[iterator.concept.contiguous]].
+[[container.opt]] lists operations that are provided for some types of
+containers but not others. Those containers for which the listed
+operations are provided shall implement the semantics described in
+[[container.opt]] unless otherwise stated. If the iterators passed to
+`lexicographical_compare_three_way` meet the constexpr iterator
+requirements [[iterator.requirements.general]] then the operations
+described in [[container.opt]] are implemented by constexpr functions.
+[*Note 6*: The algorithm `lexicographical_compare_three_way` is defined
+in [[algorithms]]. — *end note*]
 All of the containers defined in this Clause and in  [[basic.string]]
 except `array` meet the additional requirements of an allocator-aware
+container, as described in [[container.alloc.req]].
 Given an allocator type `A` and given a container type `X` having a
 `value_type` identical to `T` and an `allocator_type` identical to
 `allocator_traits<A>::rebind_alloc<T>` and given an lvalue `m` of type
 `A`, a pointer `p` of type `T*`, an expression `v` of type (possibly
 `const`) `T`, and an rvalue `rv` of type `T`, the following terms are
 defined. If `X` is not allocator-aware, the terms below are defined as
 if `A` were `allocator<T>` — no allocator object needs to be created and
 user specializations of `allocator<T>` are not instantiated:
+- `T` is **Cpp17DefaultInsertable* into `X`* means that the following
   expression is well-formed:
   ``` cpp
   allocator_traits<A>::construct(m, p)
   ```
 - An element of `X` is *default-inserted* if it is initialized by
   allocator_traits<A>::construct(m, p)
   ```
   where `p` is the address of the uninitialized storage for the element
   allocated within `X`.
+- `T` is **Cpp17MoveInsertable* into `X`* means that the following
+ expression is well-formed:
   ``` cpp
   allocator_traits<A>::construct(m, p, rv)
   ```
   and its evaluation causes the following postcondition to hold: The
   value of `*p` is equivalent to the value of `rv` before the
   evaluation.
   \[*Note 7*: `rv` remains a valid object. Its state is
   unspecified — *end note*]
+- `T` is **Cpp17CopyInsertable* into `X`* means that, in addition to `T`
+  being *Cpp17MoveInsertable* into `X`, the following expression is
   well-formed:
   ``` cpp
   allocator_traits<A>::construct(m, p, v)
   ```
   and its evaluation causes the following postcondition to hold: The
   value of `v` is unchanged and is equivalent to `*p`.
+- `T` is **Cpp17EmplaceConstructible* into `X` from `args`*, for zero or
+ more arguments `args`, means that the following expression is
+  well-formed:
   ``` cpp
   allocator_traits<A>::construct(m, p, args)
   ```
+- `T` is **Cpp17Erasable* from `X`* means that the following expression
+ is well-formed:
   ``` cpp
   allocator_traits<A>::destroy(m, p)
   ```
 [*Note 8*: A container calls
 `allocator_traits<A>::construct(m, p, args)` to construct an element at
 `p` using `args`, with `m == get_allocator()`. The default `construct`
 in `allocator` will call `::new((void*)p) T(args)`, but specialized
 allocators may choose a different definition. — *end note*]
+In [[container.alloc.req]], `X` denotes an allocator-aware container
+class with a `value_type` of `T` using allocator of type `A`, `u`
+denotes a variable, `a` and `b` denote non-const lvalues of type `X`,
+`t` denotes an lvalue or a const rvalue of type `X`, `rv` denotes a
+non-const rvalue of type `X`, and `m` is a value of type `A`.
 The behavior of certain container member functions and deduction guides
 depends on whether types qualify as input iterators or allocators. The
 extent to which an implementation determines that a type cannot be an
 input iterator is unspecified, except that as a minimum integral types
 shall not qualify as input iterators. Likewise, the extent to which an
 implementation determines that a type cannot be an allocator is
 unspecified, except that as a minimum a type `A` shall not qualify as an
+allocator unless it meets both of the following conditions:
+- The *qualified-id* `A::value_type` is valid and denotes a type
+  [[temp.deduct]].
 - The expression `declval<A&>().allocate(size_t{})` is well-formed when
   treated as an unevaluated operand.

Diff to HTML by rtfpessoa