boost_mirror/unordered
1
0
Fork 0
mirror of https://github.com/boostorg/unordered.git synced 2025-05-11 21:44:01 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix broken links

Browse Source
This commit is contained in:
Christian Mazakas 2025-01-07 14:50:21 -08:00
parent d5faa1b5cf
commit 0e768a2dca
3 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
doc/modules/ROOT/pages/buckets.adoc
View File

@ -4,7 +4,7 @@
= Basics of Hash Tables = Basics of Hash Tables
The containers are made up of a number of _buckets_, each of which can contain The containers are made up of a number of _buckets_, each of which can contain
any number of elements. For example, the following diagram shows a <<unordered_set,`boost::unordered_set`>> with 7 buckets containing 5 elements, `A`, any number of elements. For example, the following diagram shows a `xref:reference/unordered_set.adoc#unordered_set[boost::unordered_set]` with 7 buckets containing 5 elements, `A`,
`B`, `C`, `D` and `E` (this is just for illustration, containers will typically `B`, `C`, `D` and `E` (this is just for illustration, containers will typically
have more buckets). have more buckets).
@ -141,7 +141,7 @@ h|*Method* h|*Description*
A note on `max_load` for open-addressing and concurrent containers: the maximum load will be A note on `max_load` for open-addressing and concurrent containers: the maximum load will be
(`max_load_factor() * bucket_count()`) right after `rehash` or on container creation, but may (`max_load_factor() * bucket_count()`) right after `rehash` or on container creation, but may
slightly decrease when erasing elements in high-load situations. For instance, if we slightly decrease when erasing elements in high-load situations. For instance, if we
have a <<unordered_flat_map,`boost::unordered_flat_map`>> with `size()` almost have a `xref:reference/unordered_flat_map.adoc#unordered_flat_map[boost::unordered_flat_map]` with `size()` almost
at `max_load()` level and then erase 1,000 elements, `max_load()` may decrease by around a at `max_load()` level and then erase 1,000 elements, `max_load()` may decrease by around a
few dozen elements. This is done internally by Boost.Unordered in order few dozen elements. This is done internally by Boost.Unordered in order
to keep its performance stable, and must be taken into account when planning for rehash-free insertions. to keep its performance stable, and must be taken into account when planning for rehash-free insertions.

2
doc/modules/ROOT/pages/rationale.adoc
View File

@ -102,7 +102,7 @@ and *high* and *low* are the upper and lower halves of an extended word, respect
In 64-bit architectures, _C_ is the integer part of 2^64^&#8725;https://en.wikipedia.org/wiki/Golden_ratio[_&phi;_], In 64-bit architectures, _C_ is the integer part of 2^64^&#8725;https://en.wikipedia.org/wiki/Golden_ratio[_&phi;_],
whereas in 32 bits _C_ = 0xE817FB2Du has been obtained from https://arxiv.org/abs/2001.05304[Steele and Vigna (2021)^]. whereas in 32 bits _C_ = 0xE817FB2Du has been obtained from https://arxiv.org/abs/2001.05304[Steele and Vigna (2021)^].
When using a hash function directly suitable for open addressing, post-mixing can be opted out of via a dedicated <<hash_traits_hash_is_avalanching,`hash_is_avalanching`>>trait. When using a hash function directly suitable for open addressing, post-mixing can be opted out of via a dedicated `xref:reference/hash_traits.adoc#hash_traits_hash_is_avalanching[hash_is_avalanching]` trait.
`boost::hash` specializations for string types are marked as avalanching. `boost::hash` specializations for string types are marked as avalanching.
=== Platform Interoperability === Platform Interoperability

4
doc/modules/ROOT/pages/regular.adoc
View File

@ -48,7 +48,7 @@ three,3
---- ----
There are other differences, which are listed in the There are other differences, which are listed in the
<<comparison,Comparison with Associative Containers>> section. xref:regular.adoc#comparison[Comparison with Associative Containers] section.
== Iterator Invalidation == Iterator Invalidation
@ -123,7 +123,7 @@ See the xref:reference/unordered_map.adoc#unordered_map_rehash[reference for mor
|`iterator`, `const_iterator` are of at least the forward category. |`iterator`, `const_iterator` are of at least the forward category.
|Iterators, pointers and references to the container's elements are never invalidated. |Iterators, pointers and references to the container's elements are never invalidated.
|<<regular_iterator_invalidation,Iterators can be invalidated by calls to insert or rehash>>. + |xref:regular.adoc#regular_iterator_invalidation[Iterators can be invalidated by calls to insert or rehash]. +
**Node-based containers:** Pointers and references to the container's elements are never invalidated. + **Node-based containers:** Pointers and references to the container's elements are never invalidated. +
**Flat containers:** Pointers and references to the container's elements are invalidated when rehashing occurs. **Flat containers:** Pointers and references to the container's elements are invalidated when rehashing occurs.