22 Containers library [containers]

Containers are objects that store other objects.

They control allocation and deallocation of these objects through constructors, destructors, insert and erase operations.

All of the complexity requirements in this Clause are stated solely in terms of the number of operations on the contained objects.

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, 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.

In Tables 73, 74, and 75 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.

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.

begin() returns an iterator referring to the first element in the container.

end() returns an iterator which is the past-the-end value for the container.

If the container is empty, then begin() == end().

In the expressions

i == j
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 const_­iterator type referring to the same element with no change in semantics.

Unless otherwise specified, all containers defined in this clause obtain memory using an allocator (see [allocator.requirements]).

Copy constructors for these container types obtain an allocator by calling allocator_­traits<allocator_­type>​::​select_­on_­container_­copy_­construction on the allocator belonging to the container being copied.

Move 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.

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 allocator is replaced.

The allocator may be replaced only via assignment or swap().

Allocator replacement is performed by copy assignment, move assignment, or swapping of the allocator only if allocator_­traits<allocator_­type>​::​propagate_­on_­container_­copy_­assignment​::​value, allocator_­traits<allocator_­type>​::​propagate_­on_­container_­move_­assignment​::​value, or allocator_­traits<allocator_­type>​::​propagate_­on_­container_­swap​::​value is true within the implementation of the corresponding container operation.

In all container types defined in this Clause, the member get_­allocator() returns a copy of the allocator used to construct the container or, if that allocator has been replaced, a copy of the most recent replacement.

The expression a.swap(b), for containers a and b of a standard container type other than array, shall exchange the values of a and b without invoking any move, copy, or swap operations on the individual container elements.

Lvalues of any Compare, Pred, or Hash types belonging to a and b shall be swappable and shall be exchanged by calling swap as described in [swappable.requirements].

If allocator_­traits<allocator_­type>​::​propagate_­on_­container_­swap​::​value is true, then lvalues of type allocator_­type shall be swappable and the allocators of a and b shall also be exchanged by calling swap as described in [swappable.requirements].

Otherwise, the allocators shall not be swapped, and the behavior is undefined unless a.get_­allocator() == b.get_­allocator().

Every iterator referring to an 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, the container is called reversible and meets the additional requirements in Table 74.

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:

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 whose member types iterator and const_­iterator meet the Cpp17RandomAccessIterator requirements ([random.access.iterators]) and model contiguous_­iterator ([iterator.concept.contiguous]).

Table 75 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 75 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 Table 75 are implemented by constexpr functions.

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 76.

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:

In Table 76, 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:

For purposes of avoiding data races, implementations shall consider the following functions to be const: begin, end, rbegin, rend, front, back, data, find, lower_­bound, upper_­bound, equal_­range, at and, except in associative or unordered associative containers, operator[].

Notwithstanding [res.on.data.races], implementations are required to avoid data races when the contents of the contained object in different elements in the same container, excepting vector<bool>, are modified concurrently.

A sequence container organizes a finite set of objects, all of the same type, into a strictly linear arrangement.

The library provides four basic kinds of sequence containers: vector, forward_­list, list, and deque.

In addition, array is provided as a sequence container which provides limited sequence operations because it has a fixed number of elements.

The library also provides container adaptors that make it easy to construct abstract data types, such as stacks or queues, out of the basic sequence container kinds (or out of other kinds of sequence containers that the user might define).

In Tables 77 and 78, X denotes a sequence container class, a denotes a value of type X containing elements of type T, u denotes the name of a variable being declared, A denotes X​::​allocator_­type if the qualified-id X​::​allocator_­type is valid and denotes a type ([temp.deduct]) and allocator<T> if it doesn't, i and j denote iterators that meet the Cpp17InputIterator requirements and refer to elements implicitly convertible to value_­type, [i, j) denotes a valid range, il designates an object of type initializer_­list<value_­type>, n denotes a value of type X​::​size_­type, p denotes a valid constant iterator to a, q denotes a valid dereferenceable constant iterator to a, [q1, q2) denotes a valid range of constant iterators in a, t denotes an lvalue or a const rvalue of X​::​value_­type, and rv denotes a non-const rvalue of X​::​value_­type.

Args denotes a template parameter pack; args denotes a function parameter pack with the pattern Args&&.

The complexities of the expressions are sequence dependent.

The iterator returned from a.insert(p, t) points to the copy of t inserted into a.

The iterator returned from a.insert(p, rv) points to the copy of rv inserted into a.

The iterator returned from a.insert(p, n, t) points to the copy of the first element inserted into a, or p if n == 0.

The iterator returned from a.insert(p, i, j) points to the copy of the first element inserted into a, or p if i == j.

The iterator returned from a.insert(p, il) points to the copy of the first element inserted into a, or p if il is empty.

The iterator returned from a.emplace(p, args) points to the new element constructed from args into a.

The iterator returned from a.erase(q) points to the element immediately following q prior to the element being erased.

If no such element exists, a.end() is returned.

The iterator returned by a.erase(q1, q2) points to the element pointed to by q2 prior to any elements being erased.

If no such element exists, a.end() is returned.

For every sequence container defined in this Clause and in [strings]:

• (13.1)
  If the constructor

  template<class InputIterator>
    X(InputIterator first, InputIterator last,
      const allocator_type& alloc = allocator_type());
  

  is called with a type InputIterator that does not qualify as an input iterator, then the constructor shall not participate in overload resolution.
• (13.2)
  If the member functions of the forms:

  template<class InputIterator>
    return-type F(const_iterator p,
                  InputIterator first, InputIterator last);       // such as insert
  
  template<class InputIterator>
    return-type F(InputIterator first, InputIterator last);       // such as append, assign
  
  template<class InputIterator>
    return-type F(const_iterator i1, const_iterator i2,
                  InputIterator first, InputIterator last);       // such as replace
  

  are called with a type InputIterator that does not qualify as an input iterator, then these functions shall not participate in overload resolution.
• (13.3)
  A deduction guide for a sequence container shall not participate in overload resolution if it has an InputIterator template parameter and a type that does not qualify as an input iterator is deduced for that parameter, or if it has an Allocator template parameter and a type that does not qualify as an allocator is deduced for that parameter.

Table 78 lists operations that are provided for some types of sequence containers but not others.

An implementation shall provide these operations for all container types shown in the “container” column, and shall implement them so as to take amortized constant time.

The member function at() provides bounds-checked access to container elements.

at() throws out_­of_­range if n >= a.size().

The associative containers with unique keys and the unordered containers with unique keys have a member function insert that returns a nested type insert_­return_­type.

That return type is a specialization of the template specified in this subclause.

template<class Iterator, class NodeType>
struct insert-return-type
{
  Iterator position;
  bool     inserted;
  NodeType node;
};

The name insert-return-type is exposition only.

insert-return-type has the template parameters, data members, and special members specified above.

It has no base classes or members other than those specified.

Associative containers provide fast retrieval of data based on keys.

The library provides four basic kinds of associative containers: set, multiset, map and multimap.

Each associative container is parameterized on Key and an ordering relation Compare that induces a strict weak ordering on elements of Key.

In addition, map and multimap associate an arbitrary mapped type T with the Key.

The object of type Compare is called the comparison object of a container.

The phrase “equivalence of keys” means the equivalence relation imposed by the comparison object.

That is, two keys k1 and k2 are considered to be equivalent if for the comparison object comp, comp(k1, k2) == false && comp(k2, k1) == false.

For any two keys k1 and k2 in the same container, calling comp(k1, k2) shall always return the same value.

An associative container supports unique keys if it may contain at most one element for each key.

Otherwise, it supports equivalent keys.

The set and map classes support unique keys; the multiset and multimap classes support equivalent keys.

For multiset and multimap, insert, emplace, and erase preserve the relative ordering of equivalent elements.

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>.

iterator of an associative container is of the bidirectional iterator category.

For associative containers where the value type is the same as the key type, both iterator and const_­iterator are constant iterators.

It is unspecified whether or not iterator and const_­iterator are the same type.

The associative containers meet all the requirements of Allocator-aware containers, except that for map and multimap, the requirements placed on value_­type in Table 76 apply instead to key_­type and mapped_­type.

In Table 80, X denotes an associative container class, a denotes a value of type X, a2 denotes a value of a type with nodes compatible with type X (Table 79), b denotes a possibly const value of type X, u denotes the name of a variable being declared, a_­uniq denotes a value of type X when X supports unique keys, a_­eq denotes a value of type X when X supports multiple keys, a_­tran denotes a possibly const value of type X when the qualified-id X​::​key_­compare​::​is_­transparent is valid and denotes a type ([temp.deduct]), i and j meet the Cpp17InputIterator requirements and refer to elements implicitly convertible to value_­type, [i, j) denotes a valid range, p denotes a valid constant iterator to a, q denotes a valid dereferenceable constant iterator to a, r denotes a valid dereferenceable iterator to a, [q1, q2) denotes a valid range of constant iterators in a, il designates an object of type initializer_­list<value_­type>, t denotes a value of type X​::​value_­type, k denotes a value of type X​::​key_­type and c denotes a possibly const value of type X​::​key_­compare; kl is a value such that a is partitioned ([alg.sorting]) with respect to c(r, kl), with r the key value of e and e in a; ku is a value such that a is partitioned with respect to !c(ku, r); ke is a value such that a is partitioned with respect to c(r, ke) and !c(ke, r), with c(r, ke) implying !c(ke, r).

A denotes the storage allocator used by X, if any, or allocator<X​::​value_­type> otherwise, m denotes an allocator of a type convertible to A, and nh denotes a non-const rvalue of type X​::​node_­type.

The insert and emplace members shall not affect the validity of iterators and references to the container, and the erase members shall invalidate only iterators and references to the erased elements.

The extract members invalidate only iterators to the removed element; pointers and references to the removed element remain valid.

However, accessing the element through such pointers and references while the element is owned by a node_­type is undefined behavior.

References and pointers to an element obtained while it is owned by a node_­type are invalidated if the element is successfully inserted.

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, the following condition holds:

value_comp(*j, *i) == false

For associative containers with unique keys the stronger condition holds:

value_comp(*i, *j) != false

When an associative container is constructed by passing a comparison object the container shall not store a pointer or reference to the passed object, even if that object is passed by reference.

When an associative container is copied, through either a copy constructor or an assignment operator, the target container shall then use the comparison object from the container being copied, as if that comparison object had been passed to the target container in its constructor.

The member function templates find, count, contains, lower_­bound, upper_­bound, and equal_­range shall not participate in overload resolution unless the qualified-id Compare​::​is_­transparent is valid and denotes a type ([temp.deduct]).

A deduction guide for an associative container shall not participate in overload resolution if any of the following are true:

• (15.1)
  It has an InputIterator template parameter and a type that does not qualify as an input iterator is deduced for that parameter.
• (15.2)
  It has an Allocator template parameter and a type that does not qualify as an allocator is deduced for that parameter.
• (15.3)
  It has a Compare template parameter and a type that qualifies as an allocator is deduced for that parameter.

Unordered associative containers provide an ability for fast retrieval of data based on keys.

The worst-case complexity for most operations is linear, but the average case is much faster.

The library provides four unordered associative containers: unordered_­set, unordered_­map, unordered_­multiset, and unordered_­multimap.

Unordered associative containers conform to the requirements for Containers, except that the expressions a == b and a != b have different semantics than for the other container types.

Each unordered associative container is parameterized by Key, by a function object type Hash that meets the Cpp17Hash requirements ([hash.requirements]) and acts as a hash function for argument values of type Key, and by a binary predicate Pred that induces an equivalence relation on values of type Key.

Additionally, unordered_­map and unordered_­multimap associate an arbitrary mapped type T with the Key.

The container's object of type Hash — denoted by hash — is called the hash function of the container.

The container's object of type Pred — denoted by pred — is called the key equality predicate of the container.

Two values k1 and k2 are considered equivalent if the container's key equality predicate pred(k1, k2) is valid and returns true when passed those values.

If k1 and k2 are equivalent, the container's hash function shall return the same value for both.

For any two keys k1 and k2 in the same container, calling pred(k1, k2) shall always return the same value.

For any key k in a container, calling hash(k) shall always return the same value.

An unordered associative container supports unique keys if it may contain at most one element for each key.

Otherwise, it supports equivalent keys.

unordered_­set and unordered_­map support unique keys.

unordered_­multiset and unordered_­multimap support equivalent keys.

In containers that support equivalent keys, elements with equivalent keys are adjacent to each other in the iteration order of the container.

Thus, although the absolute order of elements in an unordered container is not specified, its elements are grouped into equivalent-key groups such that all elements of each group have equivalent keys.

Mutating operations on unordered containers shall preserve the relative order of elements within each equivalent-key group unless otherwise specified.

For unordered_­set and unordered_­multiset the value type is the same as the key type.

For unordered_­map and unordered_­multimap it is pair<const Key, T>.

For unordered containers where the value type is the same as the key type, both iterator and const_­iterator are constant iterators.

It is unspecified whether or not iterator and const_­iterator are the same type.

The elements of an unordered associative container are organized into buckets.

Keys with the same hash code appear in the same bucket.

The number of buckets is automatically increased as elements are added to an unordered associative container, so that the average number of elements per bucket is kept below a bound.

Rehashing invalidates iterators, changes ordering between elements, and changes which buckets elements appear in, but does not invalidate pointers or references to elements.

For unordered_­multiset and unordered_­multimap, rehashing preserves the relative ordering of equivalent elements.

The unordered associative containers meet all the requirements of Allocator-aware containers, except that for unordered_­map and unordered_­multimap, the requirements placed on value_­type in Table 76 apply instead to key_­type and mapped_­type.

In Table 81:

• (11.1)
  X denotes an unordered associative container class,
• (11.2)
  a denotes a value of type X,
• (11.3)
  a2 denotes a value of a type with nodes compatible with type X (Table 79),
• (11.4)
  b denotes a possibly const value of type X,
• (11.5)
  a_­uniq denotes a value of type X when X supports unique keys,
• (11.6)
  a_­eq denotes a value of type X when X supports equivalent keys,
• (11.7)
  a_­tran denotes a possibly const value of type X when the qualified-ids X​::​key_­equal​::​is_­transparent and X​::​hasher​::​is_­transparent are both valid and denote types ([temp.deduct]),
• (11.8)
  i and j denote input iterators that refer to value_­type,
• (11.9)
  [i, j) denotes a valid range,
• (11.10)
  p and q2 denote valid constant iterators to a,
• (11.11)
  q and q1 denote valid dereferenceable constant iterators to a,
• (11.12)
  r denotes a valid dereferenceable iterator to a,
• (11.13)
  [q1, q2) denotes a valid range in a,
• (11.14)
  il denotes a value of type initializer_­list<value_­type>,
• (11.15)
  t denotes a value of type X​::​value_­type,
• (11.16)
  k denotes a value of type key_­type,
• (11.17)
  hf denotes a possibly const value of type hasher,
• (11.18)
  eq denotes a possibly const value of type key_­equal,
• (11.19)
  ke is a value such that
  • (11.19.1)
    eq(r1, ke) == eq(ke, r1)
  • (11.19.2)
    hf(r1) == hf(ke) if eq(r1, ke) is true, and
  • (11.19.3)
    (eq(r1, ke) && eq(r1, r2)) == eq(r2, ke)
  where r1 and r2 are keys of elements in a_­tran,
• (11.20)
  n denotes a value of type size_­type,
• (11.21)
  z denotes a value of type float, and
• (11.22)
  nh denotes a non-const rvalue of type X​::​node_­type.