2. Boost Unordered Translation (zh_Hans)
3. Doc / Modules / Root / Pages / Buckets (adoc)
4. English
5. Zen

4 :11
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — image::buckets.png[] 20/10000 · 20
5 :13
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In order to decide which bucket to place an element in, the container applies the hash function, `Hash`, to the element's key (for sets the key is the whole element, but is referred to as the key so that the same terminology can be used for sets and maps). This returns a value of type `std::size_t`. `std::size_t` has a much greater range of values then the number of buckets, so the container applies another transformation to that value to choose a bucket to place the element in. 483/10000 · 483
6 :20
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Retrieving the elements for a given key is simple. The same process is applied to the key to find the correct bucket. Then the key is compared with the elements in the bucket to find any elements that match (using the equality predicate `Pred`). If the hash function has worked well the elements will be evenly distributed amongst the buckets so only a small number of elements will need to be examined. 403/10000 · 403
7 :27
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — There is xref:hash_equality.adoc#hash_equality[more information on hash functions and equality predicates in the next section]. 127/10000 · 127
8 :30
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — You can see in the diagram that `A` & `D` have been placed in the same bucket. When looking for elements in this bucket up to 2 comparisons are made, making the search slower. This is known as a *collision*. To keep things fast we try to keep collisions to a minimum. 267/10000 · 267
9 :35
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — If instead of `boost::unordered_set` we had used `xref:reference/unordered_flat_set.adoc[boost::unordered_flat_set]`, the diagram would look as follows: 152/10000 · 152
10 :38
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — image::buckets-oa.png[] 23/10000 · 23
11 :40
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In open-addressing containers, buckets can hold at most one element; if a collision happens (like is the case of `D` in the example), the element uses some other available bucket in the vicinity of the original position. Given this simpler scenario, Boost.Unordered open-addressing containers offer a very limited API for accessing buckets. 340/10000 · 340
:48 :48
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 2+^h| *All containers* h|*Method* h|*Description* 49/10000 · 49
13 :51
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `size_type bucket_count() const` 32/10000 · 32
14 :51
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The number of buckets. 22/10000 · 22
15 :54
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 2+^h| *Closed-addressing containers only* h|*Method* h|*Description* 68/10000 · 68
16 :57
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `size_type max_bucket_count() const` 36/10000 · 36
17 :57
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — An upper bound on the number of buckets. 40/10000 · 40
18 :57
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `size_type bucket_size(size_type n) const` 42/10000 · 42
19 :57
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The number of elements in bucket `n`. 37/10000 · 37
20 :57
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `size_type bucket(key_type const& k) const` 43/10000 · 43
21 :57
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Returns the index of the bucket which would contain `k`. 56/10000 · 56
22 :57
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `local_iterator begin(size_type n)` 35/10000 · 35
23 :66
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 1.6+|Return begin and end iterators for bucket `n`. 51/10000 · 51