boostorg/unordered
1
0
Fork 1
mirror of https://github.com/boostorg/unordered.git synced 2025-07-29 19:07:15 +02:00
Code Issues Packages Projects Releases Wiki Activity

fixed max_load docs

Browse Source
This commit is contained in:
joaquintides
2022-11-04 13:18:09 +01:00
parent 79379a4049
commit 3e4546465b
4 changed files with 11 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
doc/unordered/buckets.adoc
View File

@ -142,14 +142,13 @@ h|*Method* h|*Description*
|===
A note on `max_load` for open-addressing containers: the maximum load will naturally decrease when
new insertions are performed, but _won't_ increase at the same rate when erasing: for instance,
adding 1,000 elements to a <<unordered_flat_map,`boost::unordered_flat_map`>> under high load
conditions and then erasing 1,000 elements will typically reduce the maximum load by around
a few dozen elements rather than restoring it to its original value. This is done internally by Boost.Unordered in order
A note on `max_load` for open-addressing 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
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.
The maximum load will be reset to its theoretical maximum
(`max_load_factor() * bucket_count()`) right after `rehash`.
== Iterator Invalidation

2
doc/unordered/compliance.adoc
View File

@ -139,5 +139,5 @@ The main differences with C++ unordered associative containers are:
* `erase(iterator)` returns `void` instead of an iterator to the following element.
* There is no API for bucket handling (except `bucket_count`) or node extraction/insertion.
* The maximum load factor of the container is managed internally and can't be set by the user. The maximum load,
exposed through the public function `max_load`, does not increase monotonically with the number of erasures.
exposed through the public function `max_load`, may decrease on erasure under high-load conditions.

4
doc/unordered/unordered_flat_map.adoc
View File

@ -1173,8 +1173,8 @@ size_type max_load() const noexcept;
[horizontal]
Returns:;; The maximum number of elements the container can hold without rehashing, assuming that no further elements will be erased.
Note:;; After construction, rehash or clearance, the container's maximum load is at least `max_load_factor() * bucket_count()`. This load will decrease by the number of elements inserted,
but won't increase at the same rate on erasure.
Note:;; After construction, rehash or clearance, the container's maximum load is at least `max_load_factor() * bucket_count()`.
This number may decrease on erasure under high-load conditions.
---

4
doc/unordered/unordered_flat_set.adoc
View File

@ -972,8 +972,8 @@ size_type max_load() const noexcept;
[horizontal]
Returns:;; The maximum number of elements the container can hold without rehashing, assuming that no further elements will be erased.
Note:;; After construction, rehash or clearance, the container's maximum load is at least `max_load_factor() * bucket_count()`. This load will decrease by the number of elements inserted,
but won't increase at the same rate on erasure.
Note:;; After construction, rehash or clearance, the container's maximum load is at least `max_load_factor() * bucket_count()`.
This number may decrease on erasure under high-load conditions.
---