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 83),
- 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.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.alloc.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)
```

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