Exit Zen
24
:68
English
`local_iterator end(size_type n)`
33/330 · 33
24
:285
English
Typedefs
4/100 · 8
:388
:388
English
---
3/100 · 3
24
:97
English
When looking for an element with hash value _h_, SIMD technologies such as https://en.wikipedia.org/wiki/SSE2[SSE2] and https://en.wikipedia.org/wiki/ARM_architecture_family#Advanced_SIMD_(Neon)[Neon] allow us to very quickly inspect the full metadata word and look for the reduced value of _h_ among all the 15 buckets with just a handful of CPU instructions: non-matching buckets can be readily discarded, and those whose reduced hash value matches need be inspected via full comparison with the corresponding element. If the looked-for element is not present, the overflow byte is inspected:
271/5940 · 594
24
:26
English
xref:reference/header_unordered_node_set.adoc[+++<code style="color: inherit;">+++<boost/unordered/unordered_node_set.hpp>+++</code>+++ Synopsis]
153/1450 · 145
:277
:277
English
---
3/100 · 3
24
:323
English
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.
183/2980 · 298
:335
:335
English
---
3/100 · 3
:371
:371
English
---
3/100 · 3
24
:269
English
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.
182/2980 · 298
:282
:282
English
The iterator category is at least a forward iterator.
14/530 · 53
24
:320
English
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.
200/2980 · 298
24
:318
English
Typedefs
4/100 · 8
25
:25
English
xref:reference/header_unordered_flat_map_fwd.adoc[`<boost/unordered/unordered_flat_map_fwd.hpp>`]
111/970 · 97
:117
:117
English
bool operator==(point const& p1, point const& p2) { return p1.x == p2.x && p1.y == p2.y; }
106/900 · 90
25
:106
English
Access to an element previously located via lookup.
14/510 · 51
25
:100
English
Keys `k1`, `k2` are considered equivalent if `!Compare(k1, k2) && !Compare(k2, k1)`.
54/840 · 84
25
:43
English
Added Visual Studio Natvis framework custom visualizations for containers and iterators. This works for all containers with an allocator using raw pointers. In this release, containers and iterators are not supported if their allocator uses fancy pointers. This may be addressed in later releases.
111/2970 · 297
25
:56
English
The visualizations mirror the standard unordered containers. The map containers display an association from key to mapped value. The set containers display an association from index to value. An iterator is either displayed with its item, or as an end iterator. Here is what may be shown for an example `boost::unordered_map`, an example `boost::unordered_set`, and their respective begin and end iterators.
146/4070 · 407
25
:237
English
This functionality is not provided for mere syntactic convenience, though: by processing all the keys at once, some internal optimizations can be applied that increase performance over the regular, one-at-a-time case (consult the xref:benchmarks.adoc#benchmarks_boostconcurrent_flatnode_map[benchmarks]). In fact, it may be beneficial to buffer incoming keys so that they can be bulk visited in chunks:
147/4020 · 402