Exit Zen
24
:104
English
In a non-concurrent unordered container, iterators serve two main purposes:
23/750 · 75
25
:106
English
Access to an element previously located via lookup.
14/510 · 51
26
:107
English
Container traversal.
5/200 · 20
27
:109
English
In place of iterators, Boost.Unordered concurrent containers use _internal visitation_ facilities as a thread-safe substitute. Classical operations returning an iterator to an element already existing in the container, like for instance:
78/2370 · 237
28
:119
English
are transformed to accept a _visitation function_ that is passed such element:
21/780 · 78
29
:127
English
(In the second case `f` is only invoked if there's an equivalent element to `obj` in the table, not if insertion is successful). Container traversal is served by:
62/1620 · 162
30
:136
English
of which there are parallelized versions in C++17 compilers with parallel algorithm support. In general, the interface of concurrent containers is derived from that of their non-concurrent counterparts by a fairly straightforward process of replacing iterators with visitation where applicable. If for regular maps `iterator` and `const_iterator` provide mutable and const access to elements, respectively, here visitation is granted mutable or const access depending on the constness of the member function used (there are also `*cvisit` overloads for explicit const visitation); In the case of `boost::concurrent_flat_set`, visitation is always const.
217/6530 · 653
31
:145
English
One notable operation not provided by `boost::concurrent_flat_map`/`boost::concurrent_node_map` is `operator[]`/`at`, which can be replaced, if in a more convoluted manner, by `xref:reference/concurrent_flat_map.adoc#concurrent_flat_map_try_emplace_or_cvisit[try_emplace_or_visit]`.
220/2820 · 282
The translation has come to an end.