boost_mirror/unordered
1
0
Fork 0
mirror of https://github.com/boostorg/unordered.git synced 2025-05-09 23:23:59 +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
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
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
(`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
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
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.

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;_],
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.
=== 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
<<comparison,Comparison with Associative Containers>> section.
xref:regular.adoc#comparison[Comparison with Associative Containers] section.
== 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.
|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. +
**Flat containers:** Pointers and references to the container's elements are invalidated when rehashing occurs.