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

Allocator-aware containers ([container.alloc.reqmts])
other than basic_string construct elements using the function
allocator_traits<allocator_type>::rebind_traits<U>::construct
and destroy elements 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.

In [container.requirements.general],

- X denotes a container class containing objects of type T,
- a denotes a value of type X,
- b and c denote values of type (possibly const) X,
- i and j denote values of type (possibly const) X::iterator,
- u denotes an identifier,
- v denotes an lvalue of type (possibly const) X or an rvalue of type const X,
- s and t denote non-const lvalues of type X, and
- rv denotes a non-const rvalue of type X.

The following exposition-only concept is used in the definition of containers:
template<class R, class T>
concept *container-compatible-range* = // *exposition only*
ranges::input_range<R> && convertible_to<ranges::range_reference_t<R>, T>;

```
typename X::value_type
```

```
typename X::reference
```

```
typename X::const_reference
```

```
typename X::iterator
```

```
typename X::const_iterator
```

```
typename X::difference_type
```

```
typename X::size_type
```

```
X u;
X u = X();
```

```
X u(v);
X u = v;
```

```
X u(rv);
X u = rv;
```

```
t = v;
```

```
t = rv
```

```
a.~X()
```

```
b.begin()
```

```
b.end()
```

```
b.cbegin()
```

```
b.cend()
```

```
i <=> j
```

```
c == b
```

```
c != b
```

```
t.swap(s)
```

```
swap(t, s)
```

```
c.size()
```

```
c.max_size()
```

```
c.empty()
```

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

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 and inplace_vector,
shall exchange the values of a and
b without invoking any move, copy, or swap operations on the individual
container elements.

Any Compare, Pred, or Hash types
belonging to a and b shall meet the *Cpp17Swappable* requirements
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
allocator_type shall meet the *Cpp17Swappable* requirements 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.

Unless otherwise specified (see [associative.reqmts.except], [unord.req.except], [deque.modifiers], [inplace.vector.modifiers], and
[vector.modifiers])
all container types defined in this Clause meet
the following additional requirements:

- If an exception is thrown by an insert() or emplace() function while inserting a single element, that function has no effects.
- If an exception is thrown by a push_back(), push_front(), emplace_back(), or emplace_front() function, that function has no effects.
- No copy constructor or assignment operator of a returned iterator throws an exception.
- No swap() function throws an exception.

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

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 expression declval<A&>().allocate(size_t{}) is well-formed when treated as an unevaluated operand.

A type X meets the *reversible container* requirements if
X meets the container requirements,
the iterator type of X belongs to the
bidirectional or random access iterator categories ([iterator.requirements]),
and
the following types and expressions are well-formed and have
the specified semantics.

```
typename X::reverse_iterator
```

```
typename X::const_reverse_iterator
```

```
a.rbegin()
```

```
a.rend()
```

```
a.crbegin()
```

```
a.crend()
```

The following operations are provided
for some types of containers but not others.

Those containers for which the
listed operations are provided shall implement the semantics as described
unless otherwise stated.

If the iterators passed to lexicographical_compare_three_way
meet the constexpr iterator requirements ([iterator.requirements.general])
then the operations described below
are implemented by constexpr functions.

```
a <=> b
```

Except for array and inplace_vector,
all of the containers defined in [containers],
[stacktrace.basic], [basic.string], and [re.results]
meet the additional requirements of an *allocator-aware container*,
as described below.

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 that denotes
an lvalue of type T or const T or
an rvalue of type const T,
and an rvalue rv of type T,
the following terms are defined.

If X
is not allocator-aware or is a specialization of basic_string,
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
means that the following expression is well-formed: allocator_traits<A>::construct(m, p)*Cpp17DefaultInsertable*into X - 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. - T is
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.*Cpp17MoveInsertable*into X - T is
means that, in addition to T being*Cpp17CopyInsertable*into X*Cpp17MoveInsertable*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. - T is
, for zero or more arguments args, means that the following expression is well-formed: allocator_traits<A>::construct(m, p, args)*Cpp17EmplaceConstructible*into X from args - T is
means that the following expression is well-formed: allocator_traits<A>::destroy(m, p)*Cpp17Erasable*from X

In this subclause,

- X denotes an allocator-aware container class with a value_type of T using an allocator of type A,
- u denotes a variable,
- a and b denote non-const lvalues of type X,
- c denotes an lvalue of type const 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.

A type X meets the allocator-aware container requirements
if X meets the container requirements and
the following types, statements, and expressions are well-formed and have
the specified semantics.

```
typename X::allocator_type
```

```
c.get_allocator()
```

```
X u;
X u = X();
```

```
X u(m);
```

```
X u(t, m);
```

```
X u(rv);
```

```
X u(rv, m);
```

```
a = t
```

```
a = rv
```

```
a.swap(b)
```

For purposes of avoiding data races ([res.on.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 the following basic kinds of sequence containers:
vector, inplace_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,
queues,
flat_maps,
flat_multimaps,
flat_sets, or
flat_multisets, out of
the basic sequence container kinds (or out of other program-defined sequence containers).

In this subclause,

- 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
- Args denotes a template parameter pack;

A type X meets the *sequence container* requirements
if X meets the container requirements and
the following statements and expressions are well-formed and have
the specified semantics.

```
X u(n, t);
```

```
X u(i, j);
```

For vector,
if the iterator does not meet
the *Cpp17ForwardIterator* requirements ([forward.iterators]),
T is also *Cpp17MoveInsertable* into X.

```
X(from_range, rg)
```

For vector,
if R models
neither ranges::sized_range nor ranges::forward_range,
T is also *Cpp17MoveInsertable* into X.

```
X(il)
```

```
a = il
```

```
a.emplace(p, args)
```

```
a.insert(p, t)
```

```
a.insert(p, rv)
```

```
a.insert(p, n, t)
```

```
a.insert(p, i, j)
```

For vector, inplace_vector, and deque,
T is also
*Cpp17MoveInsertable* into X,
and T meets the
*Cpp17MoveConstructible*,
*Cpp17MoveAssignable*, and
*Cpp17Swappable* ([swappable.requirements]) requirements.

```
a.insert_range(p, rg)
```

```
a.insert(p, il)
```

```
a.erase(q)
```

```
a.erase(q1, q2)
```

```
a.clear()
```

```
a.assign(i, j)
```

For vector,
if the iterator does not meet
the forward iterator requirements ([forward.iterators]),
T is also *Cpp17MoveInsertable* into X.

```
a.assign_range(rg)
```

```
a.assign(il)
```

```
a.assign(n, t)
```

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

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

```
a.front()
```

```
a.back()
```

```
a.emplace_front(args)
```

```
a.emplace_back(args)
```

```
a.push_front(t)
```

```
a.push_front(rv)
```

```
a.prepend_range(rg)
```

For deque,
T is also *Cpp17MoveInsertable* into X, and
T meets the
*Cpp17MoveConstructible*,
*Cpp17MoveAssignable*, and
*Cpp17Swappable* ([swappable.requirements]) requirements.

```
a.push_back(t)
```

```
a.push_back(rv)
```

```
a.append_range(rg)
```

```
a.pop_front()
```

```
a.pop_back()
```

```
a[n]
```

```
a.at(n)
```

A *node handle* is an object that accepts ownership of a single element
from an associative container ([associative.reqmts]) or an unordered
associative container ([unord.req]).

It may be used to transfer that
ownership to another container with compatible nodes.

Containers with
compatible nodes have the same node handle type.

Table 70: Container types with compatible nodes [tab:container.node.compat]

map<K, T, C1, A> | map<K, T, C2, A> | |

map<K, T, C1, A> | multimap<K, T, C2, A> | |

set<K, C1, A> | set<K, C2, A> | |

set<K, C1, A> | multiset<K, C2, A> | |

unordered_map<K, T, H1, E1, A> | unordered_map<K, T, H2, E2, A> | |

unordered_map<K, T, H1, E1, A> | unordered_multimap<K, T, H2, E2, A> | |

unordered_set<K, H1, E1, A> | unordered_set<K, H2, E2, A> | |

unordered_set<K, H1, E1, A> | unordered_multiset<K, H2, E2, A> |

If a user-defined specialization of pair exists for
pair<const Key, T> or pair<Key, T>, where Key is the
container's key_type and T is the container's
mapped_type, the behavior of operations involving node handles is
undefined.

template<*unspecified*>
class *node-handle* {
public:
// These type declarations are described in [associative.reqmts] and [unord.req].
using value_type = *see below*; // not present for map containers
using key_type = *see below*; // not present for set containers
using mapped_type = *see below*; // not present for set containers
using allocator_type = *see below*;
private:
using container_node_type = *unspecified*; // *exposition only*
using ator_traits = allocator_traits<allocator_type>; // *exposition only*
typename ator_traits::template
rebind_traits<container_node_type>::pointer ptr_; // *exposition only*
optional<allocator_type> alloc_; // *exposition only*
public:
// [container.node.cons], constructors, copy, and assignment
constexpr *node-handle*() noexcept : ptr_(), alloc_() {}
*node-handle*(*node-handle*&&) noexcept;
*node-handle*& operator=(*node-handle*&&);
// [container.node.dtor], destructor
~*node-handle*();
// [container.node.observers], observers
value_type& value() const; // not present for map containers
key_type& key() const; // not present for set containers
mapped_type& mapped() const; // not present for set containers
allocator_type get_allocator() const;
explicit operator bool() const noexcept;
bool empty() const noexcept;
// [container.node.modifiers], modifiers
void swap(*node-handle*&)
noexcept(ator_traits::propagate_on_container_swap::value ||
ator_traits::is_always_equal::value);
friend void swap(*node-handle*& x, *node-handle*& y) noexcept(noexcept(x.swap(y))) {
x.swap(y);
}
};

*node-handle*(*node-handle*&& nh) noexcept;

*node-handle*& operator=(*node-handle*&& nh);

- If ptr_ != nullptr, destroys the value_type subobject in the container_node_type object pointed to by ptr_ by calling ator_traits::destroy, then deallocates ptr_ by calling ator_traits::template rebind_traits<container_node_type>::deallocate.
- If !alloc_ or ator_traits::propagate_on_container_move_assignment::value is true, move assigns nh.alloc_ to alloc_.

`~`*node-handle*();

```
value_type& value() const;
```

```
key_type& key() const;
```

```
mapped_type& mapped() const;
```

```
allocator_type get_allocator() const;
```

```
explicit operator bool() const noexcept;
```

```
bool empty() const noexcept;
```

`void swap(`*node-handle*& nh)
noexcept(ator_traits::propagate_on_container_swap::value ||
ator_traits::is_always_equal::value);

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;
};

Associative containers provide fast retrieval of data based on keys.

The library also provides container adaptors
that make it easy to construct abstract data types,
such as flat_maps, flat_multimaps,
flat_sets, or flat_multisets,
out of the basic sequence container kinds
(or out of other program-defined sequence containers).

Each associative container is parameterized on
Key
and an ordering relation
Compare
that induces a strict weak ordering ([alg.sorting]) on
elements of
Key.

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.

In this subclause,

- 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 70),
- b denotes a value of type X or const 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 value of type X or const 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,
- rg denotes a value of a type R
that models
*container-compatible-range*<value_type>, - 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 value of type X::key_compare or const X::key_compare;
- kl is a value such that a is partitioned ([alg.sorting]) with respect to c(x, kl), with x the key value of e and e in a;
- ku is a value such that a is partitioned with respect to !c(ku, x), with x the key value of e and e in a;
- ke is a value such that a is partitioned with respect to c(x, ke) and !c(ke, x), with c(x, ke) implying !c(ke, x) and with x the key value of e and e in a;
- kx is a value such that
- a is partitioned with respect to c(x, kx) and !c(kx, x), with c(x, kx) implying !c(kx, x) and with x the key value of e and e in a, and
- kx is not convertible to either iterator or const_iterator; and

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

A type X meets the *associative container* requirements
if X meets all the requirements of an allocator-aware
container ([container.alloc.reqmts]) and
the following types, statements, and expressions are well-formed and
have the specified semantics,
except that for
map and multimap, the requirements placed on value_type
in [container.reqmts] apply instead to key_type
and mapped_type.

```
typename X::key_type
```

```
typename X::mapped_type
```

```
typename X::value_type
```

```
typename X::key_compare
```

```
typename X::value_compare
```

```
typename X::node_type
```

```
X(c)
```

```
X u = X();
X u;
```

```
X(i, j, c)
```

```
X(i, j)
```

```
X(from_range, rg, c)
```

```
X(from_range, rg)
```

```
X(il, c)
```

```
X(il)
```

```
a = il
```

```
b.key_comp()
```

```
b.value_comp()
```

```
a_uniq.emplace(args)
```

```
a_eq.emplace(args)
```

```
a.emplace_hint(p, args)
```

```
a_uniq.insert(t)
```

```
a_eq.insert(t)
```

```
a.insert(p, t)
```

```
a.insert(i, j)
```

```
a.insert_range(rg)
```

```
a.insert(il)
```

```
a_uniq.insert(nh)
```

Otherwise if the insertion took place, inserted is true,
position points to the inserted element, and node is empty;
if the insertion failed, inserted is false,
node has the previous value of nh, and
position points to an element with a key equivalent to nh.key().

```
a_eq.insert(nh)
```

```
a.insert(p, nh)
```

```
a.extract(k)
```

```
a_tran.extract(kx)
```

```
a.extract(q)
```

```
a.merge(a2)
```

```
a.erase(k)
```

```
a_tran.erase(kx)
```

```
a.erase(q)
```

```
a.erase(r)
```

```
a.erase(q1, q2)
```

```
a.clear()
```

```
b.find(k)
```

```
a_tran.find(ke)
```

```
b.count(k)
```

```
a_tran.count(ke)
```

```
b.contains(k)
```

```
a_tran.contains(ke)
```

```
b.lower_bound(k)
```

```
a_tran.lower_bound(kl)
```

```
b.upper_bound(k)
```

```
a_tran.upper_bound(ku)
```

```
b.equal_range(k)
```

```
a_tran.equal_range(ke)
```

The insert, insert_range, 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, equal_range,
erase, and extract
shall not participate in overload resolution unless
the *qualified-id* Compare::is_transparent is valid
and denotes a type ([temp.deduct]).

Additionally, the member function templates extract and erase
shall not participate in overload resolution if
is_convertible_v<K&&, iterator> || is_convertible_v<K&&, const_iterator>
is true,
where K is the type substituted as the first template argument.

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

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

For associative containers, if an exception is thrown by any operation from
within an insert or emplace function inserting a single element, the
insertion has no effect.

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 ([container.requirements]), 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.

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

Otherwise, it supports
*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 containers where the value type is the same as the key
type, both iterator and const_iterator are constant
iterators.

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.

In this subclause,

- 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 70),
- b denotes a value of type X or const 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,
- a_tran denotes a value of type X or const X
when the
*qualified-id**s*X::key_equal::is_transparent and X::hasher::is_transparent are both valid and denote types ([temp.deduct]), - i and j denote input iterators that refer to value_type,
- [i, j) denotes a valid range,
- rg denotes a value of a type R
that models
*container-compatible-range*<value_type>, - 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 value of type hasher or const hasher,
- eq denotes a value of type key_equal or const key_equal,
- ke is a value such that
- eq(r1, ke) == eq(ke, r1),
- hf(r1) == hf(ke) if eq(r1, ke) is true, and
- if any two of eq(r1, ke), eq(r2, ke), and eq(r1, r2) are true, then all three are true,

- kx is a value such that
- eq(r1, kx) == eq(kx, r1),
- hf(r1) == hf(kx) if eq(r1, kx) is true,
- if any two of eq(r1, kx), eq(r2, kx), and eq(r1, r2) are true, then all three are true, and
- kx is not convertible to either iterator or const_iterator,

- n denotes a value of type size_type,
- z denotes a value of type float, and
- nh denotes an rvalue of type X::node_type.

A type X meets
the *unordered associative container* requirements
if X meets all the requirements of
an allocator-aware container ([container.alloc.reqmts]) and
the following types, statements, and expressions are well-formed and
have the specified semantics,
except that for unordered_map and unordered_multimap,
the requirements placed on value_type in [container.reqmts]
apply instead to key_type and mapped_type.

```
typename X::key_type
```

```
typename X::mapped_type
```

```
typename X::value_type
```

```
typename X::hasher
```

```
typename X::key_equal
```

```
typename X::local_iterator
```

```
typename X::const_local_iterator
```

```
typename X::node_type
```

```
X(n, hf, eq)
```

```
X(n, hf)
```

```
X(n)
```

```
X a = X();
X a;
```

```
X(i, j, n, hf, eq)
```

```
X(i, j, n, hf)
```

```
X(i, j, n)
```

```
X(i, j)
```

```
X(from_range, rg, n, hf, eq)
```

```
X(from_range, rg, n, hf)
```

```
X(from_range, rg, n)
```

```
X(from_range, rg)
```

```
X(il)
```

```
X(il, n)
```

```
X(il, n, hf)
```

```
X(il, n, hf, eq)
```

```
X(b)
```

```
a = b
```

```
a = il
```

```
b.hash_function()
```

```
b.key_eq()
```

```
a_uniq.emplace(args)
```

```
a_eq.emplace(args)
```

```
a.emplace_hint(p, args)
```

```
a_uniq.insert(t)
```

```
a_eq.insert(t)
```

```
a.insert(p, t)
```

```
a.insert(i, j)
```

```
a.insert_range(rg)
```

```
a.insert(il)
```

```
a_uniq.insert(nh)
```

```
a_eq.insert(nh)
```

```
a.insert(q, nh)
```

Otherwise, inserts the element owned by nh if and only if
there is no element with key equivalent to nh.key()
in containers with unique keys;
always inserts the element owned by nh
in containers with equivalent keys.

The iterator q is a hint pointing to where the search should start.

Implementations are permitted to ignore the hint.

```
a.extract(k)
```

```
a_tran.extract(kx)
```

```
a.extract(q)
```

```
a.merge(a2)
```

```
a.erase(k)
```

```
a_tran.erase(kx)
```

```
a.erase(q)
```

```
a.erase(r)
```

```
a.erase(q1, q2)
```

```
a.clear()
```

```
b.find(k)
```

```
a_tran.find(ke)
```

```
b.count(k)
```

```
a_tran.count(ke)
```

```
b.contains(k)
```

```
a_tran.contains(ke)
```

```
b.equal_range(k)
```

```
a_tran.equal_range(ke)
```

```
b.bucket_count()
```

```
b.max_bucket_count()
```

```
b.bucket(k)
```

```
a_tran.bucket(ke)
```

```
b.bucket_size(n)
```

```
b.begin(n)
```

```
b.end(n)
```

```
b.cbegin(n)
```

```
b.cend(n)
```

```
b.load_factor()
```

```
b.max_load_factor()
```

```
a.max_load_factor(z)
```

```
a.rehash(n)
```

```
a.reserve(n)
```

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 in the worst case, where N is
a.size().

For unordered_multiset and unordered_multimap,
the complexity of operator== is proportional to
in the average case and to in the worst case, where N is a.size(),
and is the size of the equivalent-key group in a.

However, if the respective elements of each corresponding pair of
equivalent-key groups and 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 , e.g., for
a pathologically bad hash function).

The insert, insert_range, 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, insert_range, 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.

The member function templates
find, count, equal_range, contains,
extract, erase, and bucket
shall not participate in overload resolution unless
the *qualified-id**s*
Pred::is_transparent and
Hash::is_transparent
are both valid and denote types ([temp.deduct]).

Additionally, the member function templates extract and erase
shall not participate in overload resolution if
is_convertible_v<K&&, iterator> || is_convertible_v<K&&, const_iterator>
is true,
where K is the type substituted as the first template argument.

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

- It has an InputIterator template parameter and a type that does not qualify as an input iterator is deduced for that parameter.
- It has an Allocator template parameter and a type that does not qualify as an allocator is deduced for that parameter.
- It has a Hash template parameter and an integral type or a type that qualifies as an allocator is deduced for that parameter.
- It has a Pred template parameter and a type that qualifies as an allocator is deduced for that parameter.

For unordered associative containers, if an exception is thrown by any
operation other than the container's hash function from within an
insert or emplace function inserting a single element,
the insertion has no effect.

For unordered associative containers, no swap function throws
an exception unless that exception is thrown by the swap of the container's
Hash or Pred object (if any).