2. Boost Unordered Translation (zh_Hans)
3. English
4. Zen

3 :6
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Forward declares all the definitions in xref:reference/header_unordered_node_set.adoc[`<boost/unordered/unordered_node_set.hpp>`]. 130/10000 · 130
3 :6
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Forward declares all the definitions in xref:reference/header_concurrent_flat_set.adoc[`<boost/unordered/concurrent_flat_set.hpp>`]. 132/10000 · 132
4 :4
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — xref:regular.adoc[] 19/10000 · 19
4 :16
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — For readers without previous experience with hash containers but familiar with normal associative containers (`std::set`, `std::map`, `std::multiset` and `std::multimap`), Boost.Unordered containers are used in a similar manner: 228/10000 · 228
4 :13
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — {cpp} introduced __unordered associative containers__ `std::unordered_set`, `std::unordered_map`, `std::unordered_multiset` and `std::unordered_multimap` in {cpp}11, but research on hash tables hasn't stopped since: advances in CPU architectures such as more powerful caches, link:https://en.wikipedia.org/wiki/Single_instruction,_multiple_data[SIMD] operations and increasingly available link:https://en.wikipedia.org/wiki/Multi-core_processor[multicore processors] open up possibilities for improved hash-based data structures and new use cases that are simply beyond reach of unordered associative containers as specified in 2011. 633/10000 · 633
4 :9
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `boost::unordered_[multi]set` and `boost::unordered_[multi]map` adhere to the standard requirements for unordered associative containers, so the interface was fixed. But there are still some implementation decisions to make. The priorities are conformance to the standard and portability. 288/10000 · 288
4 :12
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — ```cpp template < class Key, class Mapped, class Hash = boost::hash<Key>, class Pred = std::equal_to<Key>, class Alloc = std::allocator<std::pair<Key const, Mapped> > > class unordered_map; ``` 193/10000 · 193
4 :8
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — All benchmarks were created using `unordered_set<unsigned int>` (non-duplicate) and `unordered_multiset<unsigned int>` (duplicate). The source code can be https://github.com/boostorg/boost_unordered_benchmarks/tree/boost_unordered_set[found here^]. 248/10000 · 248
4 :8
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — An introduction to the standard unordered containers. 53/10000 · 53
4 :36
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In the example above, threads access `m` without synchronization, just as we'd do in a single-threaded scenario. In an ideal setting, if a given workload is distributed among _N_ threads, execution is _N_ times faster than with one thread —this limit is never attained in practice due to synchronization overheads and _contention_ (one thread waiting for another to leave a locked portion of the map), but Boost.Unordered concurrent containers are designed to perform with very little overhead and typically achieve _linear scaling_ (that is, performance is proportional to the number of threads up to the number of logical cores in the CPU). 642/10000 · 642
4 :12
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Closed-addressing containers in Boost.Unordered are fairly robust against hash functions with less-than-ideal quality, but open-addressing and concurrent containers are much more sensitive to this factor, and their performance can degrade dramatically if the hash function is not appropriate. In general, if you're using functions provided by or generated with link:../../../../container_hash/index.html[Boost.Hash^], the quality will be adequate, but you have to be careful when using alternative hash algorithms. 514/10000 · 514
4 :11
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — image::buckets.png[] 20/10000 · 20
4 :8
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Closed-addressing Containers 28/10000 · 28
4 :16
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Boost.Unordered sports one of the fastest implementations of closed addressing, also commonly known as https://en.wikipedia.org/wiki/Hash_table#Separate_chaining[separate chaining]. An example figure representing the data structure is below: 241/10000 · 241
4 :8
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — All containers and iterators have custom visualizations in the Natvis framework. 80/10000 · 80
4 :8
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Copyright (C) 2003, 2004 Jeremy B. Maitin-Shepard 49/10000 · 49
4 :6
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — xref:reference/header_unordered_map.adoc[+++<code style="color: inherit;">+++<boost/unordered/unordered_map.hpp>+++</code>+++ Synopsis] 135/10000 · 135
4 :11
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Deprecated `boost::unordered::hash_is_avalanching` is now a using-declaration of 80/10000 · 80
4 :8
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Synopsis 8/10000 · 8
4 :22
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Note:;; This header is deprecated. Use instead `link:../../../../../container_hash/doc/html/hash.html#ref_hash_is_avalanchinghash[boost::hash_is_avalanching]` defined in `link:../../../../../container_hash/doc/html/hash.html#ref_boostcontainer_hashhash_is_avalanching_hpp[<boost/container_hash/hash_is_avalanching.hpp>]`. 321/10000 · 321