Skip to content

Commit

Permalink
fix broken links
Browse files Browse the repository at this point in the history
  • Loading branch information
cmazakas committed Jan 7, 2025
1 parent d5faa1b commit 0e768a2
Show file tree
Hide file tree
Showing 3 changed files with 5 additions and 5 deletions.
4 changes: 2 additions & 2 deletions doc/modules/ROOT/pages/buckets.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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).

Expand Down Expand Up @@ -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 changes: 1 addition & 1 deletion doc/modules/ROOT/pages/rationale.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
4 changes: 2 additions & 2 deletions doc/modules/ROOT/pages/regular.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down Expand Up @@ -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.

Expand Down

0 comments on commit 0e768a2

Please sign in to comment.