26 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. [ Example: The copy constructor of type vector<vector<int>> has linear complexity, even though the complexity of copying each contained vector<int> is itself linear.  — end example ]

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. [ Note: 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 83, 84, and 85 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: 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.

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

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]). [ Note: In particular, containers and iterators do not store references to allocated elements other than through the allocator's pointer type, i.e., as objects of type P or pointer_­traits<P>​::​template rebind<unspecified>, where P is allocator_­traits<allocator_­type>​::​pointer.  — end note ] 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. [ Note: 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 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 satisfies the additional requirements in Table 84.

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:

• (11.1)

  if an exception is thrown by an insert() or emplace() function while inserting a single element, that function has no effects.

• (11.2)

  if an exception is thrown by a push_­back(), push_­front(), emplace_­back(), or emplace_­front() function, that function has no effects.

• (11.3)

  no erase(), clear(), pop_­back() or pop_­front() function throws an exception.

• (11.4)

  no copy constructor or assignment operator of a returned iterator throws an exception.

• (11.5)

  no swap() function throws an exception.

• (11.6)

  no swap() function invalidates any references, pointers, or iterators referring to the elements of the containers being swapped. [ Note: The end() iterator does not refer to any element, so it may be invalidated.  — end note ]

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 and whose member types iterator and const_­iterator are contiguous iterators.

Table 85 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 85 unless otherwise stated.

[ Note: 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 86.

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:

• (15.1)

  T is DefaultInsertable into X means that the following expression is well-formed:

  allocator_traits<A>::construct(m, p)

• (15.2)

  An element of X is default-inserted if it is initialized by evaluation of the expression

  allocator_traits<A>::construct(m, p)

  where p is the address of the uninitialized storage for the element allocated within X.

• (15.3)

  T is MoveInsertable into X means that the following expression is well-formed:

  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: rv remains a valid object. Its state is unspecified  — end note ]

• (15.4)

  T is CopyInsertable into X means that, in addition to T being MoveInsertable into X, the following expression is well-formed:

  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.

• (15.5)

  T is EmplaceConstructible into X from args, for zero or more arguments args, means that the following expression is well-formed:

  allocator_traits<A>::construct(m, p, args)

• (15.6)

  T is Erasable from X means that the following expression is well-formed:

  allocator_traits<A>::destroy(m, p)

[ Note: 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 86, 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:

• (17.1)

  The qualified-id A​::​value_­type is valid and denotes a type ([temp.deduct]).

• (17.2)

  The expression declval<A&>().allocate(size_­t{}) is well-formed when treated as an unevaluated operand.

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.

[ Note: For a vector<int> x with a size greater than one, x[1] = 5 and *x.begin() = 10 can be executed concurrently without a data race, but x[0] = 5 and *x.begin() = 10 executed concurrently may result in a data race. As an exception to the general rule, for a vector<bool> y, y[0] = true may race with y[1] = true.  — end note ]

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

The sequence containers offer the programmer different complexity trade-offs and should be used accordingly. vector or array is the type of sequence container that should be used by default. list or forward_­list should be used when there are frequent insertions and deletions from the middle of the sequence. deque is the data structure of choice when most insertions and deletions take place at the beginning or at the end of the sequence.

In Tables 87 and 88, 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 satisfying input iterator 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 Clause [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 88 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 type 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 and not the operator== on keys. 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. [ Note: iterator and const_­iterator have identical semantics in this case, and iterator is convertible to const_­iterator. Users can avoid violating the one-definition rule by always using const_­iterator in their function parameter lists.  — end note ]

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 83 apply instead to key_­type and mapped_­type. [ Note: For example, in some cases key_­type and mapped_­type are required to be CopyAssignable even though the associated value_­type, pair<const key_­type, mapped_­type>, is not CopyAssignable.  — end note ]

In Table 90, 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 89), 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 satisfy input iterator 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 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, either through 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, 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 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 of type Key are considered equivalent if the container's key equality predicate returns true when passed those values. If k1 and k2 are equivalent, the container's hash function shall return the same value for both. [ Note: Thus, when an unordered associative container is instantiated with a non-default Pred parameter it usually needs a non-default Hash parameter as well.  — end note ] 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. [ Note: iterator and const_­iterator have identical semantics in this case, and iterator is convertible to const_­iterator. Users can avoid violating the one-definition rule by always using const_­iterator in their function parameter lists.  — end note ]

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 83 apply instead to key_­type and mapped_­type. [ Note: For example, key_­type and mapped_­type are sometimes required to be CopyAssignable even though the associated value_­type, pair<const key_­type, mapped_­type>, is not CopyAssignable.  — end note ]

In Table 91: X denotes an unordered associative container class, a denotes a value of type X, a2 denotes a value of a type with nodes compatible with type X (Table 89), b denotes a possibly const value of type X, a_­uniq denotes a value of type X when X supports unique keys, a_­eq denotes a value of type X when X supports equivalent keys, i and j denote input iterators that refer to value_­type, [i, j) denotes a valid range, p and q2 denote valid constant iterators to a, q and q1 denote valid dereferenceable constant iterators to a, r denotes a valid dereferenceable iterator to a, [q1, q2) denotes a valid range in a, il denotes a value of type initializer_­list<value_­type>, t denotes a value of type X​::​value_­type, k denotes a value of type key_­type, hf denotes a possibly const value of type hasher, eq denotes a possibly const value of type key_­equal, n denotes a value of type size_­type, z denotes a value of type float, and nh denotes a non-const rvalue of type X​::​node_­type.

Two unordered containers a and b compare equal if a.size() == b.size() and, for every equivalent-key group [Ea1, Ea2) obtained from a.equal_­range(Ea1), there exists an equivalent-key group [Eb1, Eb2) obtained from b.equal_­range(Ea1), such that is_­permutation(Ea1, Ea2, Eb1, Eb2) returns true. For unordered_­set and unordered_­map, the complexity of operator== (i.e., the number of calls to the == operator of the value_­type, to the predicate returned by key_­eq(), and to the hasher returned by hash_­function()) is proportional to N in the average case and to $N^2$ in the worst case, where N is a.size(). For unordered_­multiset and unordered_­multimap, the complexity of operator== is proportional to $\sum E_i^2$ in the average case and to $N^2$ in the worst case, where N is a.size(), and $E_i$ is the size of the $i^{\text{th}}$ equivalent-key group in a. However, if the respective elements of each corresponding pair of equivalent-key groups $E{a}_i$ and $E{b}_i$ are arranged in the same order (as is commonly the case, e.g., if a and b are unmodified copies of the same container), then the average-case complexity for unordered_­multiset and unordered_­multimap becomes proportional to N (but worst-case complexity remains $O\left(N^2\right)$, e.g., for a pathologically bad hash function). The behavior of a program that uses operator== or operator!= on unordered containers is undefined unless the Hash and Pred function objects respectively have the same behavior for both containers and the equality comparison function for Key is a refinement257 of the partition into equivalent-key groups produced by Pred.

The iterator types iterator and const_­iterator of an unordered associative container are of at least the forward iterator category. For unordered associative containers where the key type and value type are the same, both iterator and const_­iterator are constant iterators.

The insert and emplace members shall not affect the validity of references to container elements, but may invalidate all iterators to the container. The erase members shall invalidate only iterators and references to the erased elements, and preserve the relative order of the elements that are not erased.

The insert and emplace members shall not affect the validity of iterators if (N+n) <= z * B, where N is the number of elements in the container prior to the insert operation, n is the number of elements inserted, B is the container's bucket count, and z is the container's maximum load factor.

The extract members invalidate only iterators to the removed element, and preserve the relative order of the elements that are not erased; 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.

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

• (17.1)

  It has an InputIterator template parameter and a type that does not qualify as an input iterator is deduced for that parameter.

• (17.2)

  It has an Allocator template parameter and a type that does not qualify as an allocator is deduced for that parameter.

• (17.3)

  It has a Hash template parameter and an integral type or a type that qualifies as an allocator is deduced for that parameter.

• (17.4)

  It has a Pred template parameter and a type that qualifies as an allocator is deduced for that parameter.