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

typos/editorial

Browse Source
This commit is contained in:
joaquintides
2023-05-19 10:51:00 +02:00
parent f1bc948be8
commit a140de4254
5 changed files with 9 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
doc/unordered/buckets.adoc
View File

@ -52,8 +52,7 @@ h|*Method* h|*Description*
|`size_type bucket_count() const` |`size_type bucket_count() const`
|The number of buckets. |The number of buckets.
2+^h| *Closed-addressing containers only* + 2+^h| *Closed-addressing containers only*
`boost::unordered_[multi]set`, `boost::unordered_[multi]map`
h|*Method* h|*Description* h|*Method* h|*Description*
|`size_type max_bucket_count() const` |`size_type max_bucket_count() const`
@ -132,10 +131,7 @@ h|*Method* h|*Description*
|`void rehash(size_type n)` |`void rehash(size_type n)`
|Changes the number of buckets so that there at least `n` buckets, and so that the load factor is less than the maximum load factor. |Changes the number of buckets so that there at least `n` buckets, and so that the load factor is less than the maximum load factor.
2+^h| *Open-addressing and concurrent containers only* + 2+^h| *Open-addressing and concurrent containers only*
`boost::unordered_flat_set`, `boost::unordered_flat_map` +
`boost::unordered_node_set`, `boost::unordered_node_map` +
`boost::concurrent_flat_map`
h|*Method* h|*Description* h|*Method* h|*Description*
|`size_type max_load() const` |`size_type max_load() const`

2
doc/unordered/compliance.adoc
View File

@ -161,7 +161,7 @@ In a non-concurrent unordered container, iterators serve two main purposes:
* Access to an element previously located via lookup. * Access to an element previously located via lookup.
* Container traversal. * Container traversal.
In place of iterators, `boost::unordered_flat_map` uses _internal visitation_ In place of iterators, `boost::concurrent_flat_map` uses _internal visitation_
facilities as a thread-safe substitute. Classical operations returning an iterator to an facilities as a thread-safe substitute. Classical operations returning an iterator to an
element already existing in the container, like for instance: element already existing in the container, like for instance:

6
doc/unordered/hash_equality.adoc
View File

@ -20,14 +20,14 @@ class unordered_map;
The hash function comes first as you might want to change the hash function The hash function comes first as you might want to change the hash function
but not the equality predicate. For example, if you wanted to use the but not the equality predicate. For example, if you wanted to use the
http://www.isthe.com/chongo/tech/comp/fnv/[FNV-1 hash^] you could write: https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function#FNV-1a_hash[FNV-1a hash^] you could write:
``` ```
boost::unordered_map<std::string, int, hash::fnv_1> boost::unordered_map<std::string, int, hash::fnv_1a>
dictionary; dictionary;
``` ```
There is an link:../../examples/fnv1.hpp[implementation of FNV-1^] in the examples directory. There is an link:../../examples/fnv1.hpp[implementation of FNV-1a^] in the examples directory.
If you wish to use a different equality function, you will also need to use a matching hash function. For example, to implement a case insensitive dictionary you need to define a case insensitive equality predicate and hash function: If you wish to use a different equality function, you will also need to use a matching hash function. For example, to implement a case insensitive dictionary you need to define a case insensitive equality predicate and hash function:

2
doc/unordered/intro.adoc
View File

@ -43,7 +43,7 @@ boost::unordered_node_map
boost::unordered_flat_map boost::unordered_flat_map
^.^h|*Concurrent* ^.^h|*Concurrent*
^| N/A ^|
^| `boost::concurrent_flat_map` ^| `boost::concurrent_flat_map`
|=== |===

4
doc/unordered/regular.adoc
View File

@ -6,7 +6,7 @@
Boost.Unordered closed-addressing containers (`boost::unordered_set`, `boost::unordered_map`, Boost.Unordered closed-addressing containers (`boost::unordered_set`, `boost::unordered_map`,
`boost::unordered_multiset` and `boost::unordered_multimap`) are fully conformant with the `boost::unordered_multiset` and `boost::unordered_multimap`) are fully conformant with the
C++ specification for unordered associative containers, so for those who know how to use C++ specification for unordered associative containers, so for those who know how to use
`std::unordered_set`, `std::unordered_map`, etc., their homonyms in Boost:Unordered are `std::unordered_set`, `std::unordered_map`, etc., their homonyms in Boost.Unordered are
drop-in replacements. The interface of open-addressing containers (`boost::unordered_node_set`, drop-in replacements. The interface of open-addressing containers (`boost::unordered_node_set`,
`boost::unordered_node_map`, `boost::unordered_flat_set` and `boost::unordered_flat_map`) `boost::unordered_node_map`, `boost::unordered_flat_set` and `boost::unordered_flat_map`)
is very similar, but they present some minor differences listed in the dedicated is very similar, but they present some minor differences listed in the dedicated
@ -62,7 +62,7 @@ invalidated by calls to `insert`, `rehash` and `reserve`.
As for pointers and references, As for pointers and references,
they are never invalidated for node-based containers they are never invalidated for node-based containers
(`boost::unordered_[multi]set`, `boost::unordered_[multi]map`, `boost::unordered_node_set`, `boost::unordered_node_map`), (`boost::unordered_[multi]set`, `boost::unordered_[multi]map`, `boost::unordered_node_set`, `boost::unordered_node_map`),
but they will when rehashing occurs for but they will be when rehashing occurs for
`boost::unordered_flat_set` and `boost::unordered_flat_map`: this is because `boost::unordered_flat_set` and `boost::unordered_flat_map`: this is because
these containers store elements directly into their holding buckets, so these containers store elements directly into their holding buckets, so
when allocating a new bucket array the elements must be transferred by means of move construction. when allocating a new bucket array the elements must be transferred by means of move construction.