2. Boost Unordered Translation (zh_Hans)
3. Doc / Modules / Root / Pages / Reference / Concurrent Flat Map (adoc)
4. English
5. Zen

18 :344
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — _Allocator_ 11/10000 · 11
19 :344
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — An allocator whose value type is the same as the table's value type. 68/10000 · 68
20 :354
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Allocators using https://en.cppreference.com/w/cpp/named_req/Allocator#Fancy_pointers[fancy pointers] are supported. 116/10000 · 116
21 :358
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The elements of the table are held into an internal _bucket array_. An element is inserted into a bucket determined by its hash code, but if the bucket is already occupied (a _collision_), an available one in the vicinity of the original position is used. 255/10000 · 255
22 :362
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The size of the bucket array can be automatically increased by a call to `insert`/`emplace`, or as a result of calling `rehash`/`reserve`. The _load factor_ of the table (number of elements divided by number of buckets) is never greater than `max_load_factor()`, except possibly for small sizes where the implementation may decide to allow for higher loads. 357/10000 · 357
23 :367
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — If `link:../../../../../container_hash/doc/html/hash.html#ref_hash_is_avalanchinghash[hash_is_avalanching]<Hash>::value` is `true`, the hash function is used as-is; otherwise, a bit-mixing post-processing stage is added to increase the quality of hashing at the expense of extra computational cost. 298/10000 · 298
:371 :371
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — --- 3/10000 · 3
25 :373
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Concurrency Requirements and Guarantees 39/10000 · 39
26 :375
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Concurrent invocations of `operator()` on the same const instance of `Hash` or `Pred` are required to not introduce data races. For `Alloc` being either `Allocator` or any allocator type rebound from `Allocator`, concurrent invocations of the following operations on the same instance `al` of `Alloc` are required to not introduce data races: 342/10000 · 342
27 :380
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Copy construction from `al` of an allocator rebound from `Alloc` 64/10000 · 64
28 :381
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `std::allocator_traits<Alloc>::allocate` 40/10000 · 40
29 :382
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `std::allocator_traits<Alloc>::deallocate` 42/10000 · 42
30 :383
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `std::allocator_traits<Alloc>::construct` 41/10000 · 41
31 :384
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `std::allocator_traits<Alloc>::destroy` 39/10000 · 39
32 :386
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In general, these requirements on `Hash`, `Pred` and `Allocator` are met if these types are not stateful or if the operations only involve constant access to internal data members. 180/10000 · 180
33 :389
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — With the exception of destruction, concurrent invocations of any operation on the same instance of a `concurrent_flat_map` do not introduce data races — that is, they are thread-safe. 183/10000 · 183
34 :392
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — If an operation *op* is explicitly designated as _blocking on_ `x`, where `x` is an instance of a `boost::concurrent_flat_map`, prior blocking operations on `x` synchronize with *op*. So, blocking operations on the same `concurrent_flat_map` execute sequentially in a multithreaded scenario. 291/10000 · 291
35 :396
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — An operation is said to be _blocking on rehashing of_ ``__x__`` if it blocks on `x` only when an internal rehashing is issued. 126/10000 · 126
36 :399
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — When executed internally by a `boost::concurrent_flat_map`, the following operations by a user-provided visitation function on the element passed do not introduce data races: 174/10000 · 174
37 :402
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Read access to the element. 27/10000 · 27