<?xml version="1.0" encoding="UTF-8"?>
<xliff xmlns="urn:oasis:names:tc:xliff:document:1.1" version="1.1">
  <file original="NoName" source-language="en" datatype="plaintext" target-language="en">
    <body>
      <trans-unit xml:space="preserve" approved="no" id="c9c8cde85ce1e43b" weblate-flags="read-only, safe-html, strict-same">
        <source>:idprefix: rationale_</source>
        <target state="translated">:idprefix: rationale_</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">3</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f92df5375eb7d5c1" weblate-flags="read-only, safe-html, strict-same">
        <source>= Implementation Rationale</source>
        <target state="translated">= Implementation Rationale</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">5</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4ebc6f95b2d9f420" weblate-flags="read-only, safe-html, strict-same">
        <source>Closed-addressing Containers</source>
        <target state="translated">Closed-addressing Containers</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">7</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ae88e4e8002516dc" weblate-flags="read-only, safe-html, strict-same">
        <source>`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.</source>
        <target state="translated">`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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">9</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ac1f97a2d06e563d" weblate-flags="read-only, safe-html, strict-same">
        <source>The http://en.wikipedia.org/wiki/Hash_table[Wikipedia article on hash tables^] has a good summary of the implementation issues for hash tables in general.</source>
        <target state="translated">The http://en.wikipedia.org/wiki/Hash_table[Wikipedia article on hash tables^] has a good summary of the implementation issues for hash tables in general.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">15</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="672d16b640d179d9" weblate-flags="read-only, safe-html, strict-same">
        <source>Data Structure</source>
        <target state="translated">Data Structure</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">18</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="cc417e9af07d8988" weblate-flags="read-only, safe-html, strict-same">
        <source>By specifying an interface for accessing the buckets of the container the standard pretty much requires that the hash table uses closed addressing.</source>
        <target state="translated">By specifying an interface for accessing the buckets of the container the standard pretty much requires that the hash table uses closed addressing.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">20</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="14d3e005448158b9" weblate-flags="read-only, safe-html, strict-same">
        <source>It would be conceivable to write a hash table that uses another method. For example, it could use open addressing, and use the lookup chain to act as a bucket but there are some serious problems with this:</source>
        <target state="translated">It would be conceivable to write a hash table that uses another method. For example, it could use open addressing, and use the lookup chain to act as a bucket but there are some serious problems with this:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">23</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e3335b5b3e20a74d" weblate-flags="read-only, safe-html, strict-same">
        <source>The standard requires that pointers to elements aren't invalidated, so</source>
        <target state="translated">The standard requires that pointers to elements aren't invalidated, so</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">27</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="81e744428bc51284" weblate-flags="read-only, safe-html, strict-same">
        <source>the elements can't be stored in one array, but will need a layer of indirection instead - losing the efficiency and most of the memory gain, the main advantages of open addressing.</source>
        <target state="translated">the elements can't be stored in one array, but will need a layer of indirection instead - losing the efficiency and most of the memory gain, the main advantages of open addressing.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">28</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1d198a54042d963b" weblate-flags="read-only, safe-html, strict-same">
        <source>Local iterators would be very inefficient and may not be able to</source>
        <target state="translated">Local iterators would be very inefficient and may not be able to</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">31</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="eb9be29e6d5de2ae" weblate-flags="read-only, safe-html, strict-same">
        <source>meet the complexity requirements.</source>
        <target state="translated">meet the complexity requirements.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">32</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b119372c3b600558" weblate-flags="read-only, safe-html, strict-same">
        <source>There are also the restrictions on when iterators can be invalidated. Since</source>
        <target state="translated">There are also the restrictions on when iterators can be invalidated. Since</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">33</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="788b9d397b0340cc" weblate-flags="read-only, safe-html, strict-same">
        <source>open addressing degrades badly when there are a high number of collisions the restrictions could prevent a rehash when it's really needed. The maximum load factor could be set to a fairly low value to work around this - but the standard requires that it is initially set to 1.0.</source>
        <target state="translated">open addressing degrades badly when there are a high number of collisions the restrictions could prevent a rehash when it's really needed. The maximum load factor could be set to a fairly low value to work around this - but the standard requires that it is initially set to 1.0.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">34</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2e676fd59434bc5e" weblate-flags="read-only, safe-html, strict-same">
        <source>And since the standard is written with a eye towards closed</source>
        <target state="translated">And since the standard is written with a eye towards closed</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">38</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3959e8d4e009224a" weblate-flags="read-only, safe-html, strict-same">
        <source>addressing, users will be surprised if the performance doesn't reflect that.</source>
        <target state="translated">addressing, users will be surprised if the performance doesn't reflect that.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">39</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b9fac45d004d2dea" weblate-flags="read-only, safe-html, strict-same">
        <source>So closed addressing is used.</source>
        <target state="translated">So closed addressing is used.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">41</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f0b1e97849053ac9" weblate-flags="read-only, safe-html, strict-same">
        <source>Number of Buckets</source>
        <target state="translated">Number of Buckets</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">43</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="51ef5b35c85e894c" weblate-flags="read-only, safe-html, strict-same">
        <source>There are two popular methods for choosing the number of buckets in a hash table. One is to have a prime number of buckets, another is to use a power of 2.</source>
        <target state="translated">There are two popular methods for choosing the number of buckets in a hash table. One is to have a prime number of buckets, another is to use a power of 2.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">45</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8d5f2a8660580d9a" weblate-flags="read-only, safe-html, strict-same">
        <source>Using a prime number of buckets, and choosing a bucket by using the modulus of the hash function's result will usually give a good result. The downside is that the required modulus operation is fairly expensive. This is what the containers used to do in most cases.</source>
        <target state="translated">Using a prime number of buckets, and choosing a bucket by using the modulus of the hash function's result will usually give a good result. The downside is that the required modulus operation is fairly expensive. This is what the containers used to do in most cases.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">49</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="bfcf336c3c238937" weblate-flags="read-only, safe-html, strict-same">
        <source>Using a power of 2 allows for much quicker selection of the bucket to use, but at the expense of losing the upper bits of the hash value. For some specially designed hash functions it is possible to do this and still get a good result but as the containers can take arbitrary hash functions this can't be relied on.</source>
        <target state="translated">Using a power of 2 allows for much quicker selection of the bucket to use, but at the expense of losing the upper bits of the hash value. For some specially designed hash functions it is possible to do this and still get a good result but as the containers can take arbitrary hash functions this can't be relied on.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">54</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7bd09e6b42a1fad8" weblate-flags="read-only, safe-html, strict-same">
        <source>To avoid this a transformation could be applied to the hash function, for an example see http://web.archive.org/web/20121102023700/http://www.concentric.net/~Ttwang/tech/inthash.htm[Thomas Wang's article on integer hash functions^]. Unfortunately, a transformation like Wang's requires knowledge of the number of bits in the hash value, so it was only used when `size_t` was 64 bit.</source>
        <target state="translated">To avoid this a transformation could be applied to the hash function, for an example see http://web.archive.org/web/20121102023700/http://www.concentric.net/~Ttwang/tech/inthash.htm[Thomas Wang's article on integer hash functions^]. Unfortunately, a transformation like Wang's requires knowledge of the number of bits in the hash value, so it was only used when `size_t` was 64 bit.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">60</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="14d978546d3d3684" weblate-flags="read-only, safe-html, strict-same">
        <source>Since release 1.79.0, https://en.wikipedia.org/wiki/Hash_function#Fibonacci_hashing[Fibonacci hashing] is used instead. With this implementation, the bucket number is determined by using `(h * m) &gt;&gt; (w - k)`, where `h` is the hash value, `m` is `2^w` divided by the golden ratio, `w` is the word size (32 or 64), and `2^k` is the number of buckets. This provides a good compromise between speed and distribution.</source>
        <target state="translated">Since release 1.79.0, https://en.wikipedia.org/wiki/Hash_function#Fibonacci_hashing[Fibonacci hashing] is used instead. With this implementation, the bucket number is determined by using `(h * m) &gt;&gt; (w - k)`, where `h` is the hash value, `m` is `2^w` divided by the golden ratio, `w` is the word size (32 or 64), and `2^k` is the number of buckets. This provides a good compromise between speed and distribution.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">66</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="74794018715d38dd" weblate-flags="read-only, safe-html, strict-same">
        <source>Since release 1.80.0, prime numbers are chosen for the number of buckets in tandem with sophisticated modulo arithmetic. This removes the need for "mixing" the result of the user's hash function as was used for release 1.79.0.</source>
        <target state="translated">Since release 1.80.0, prime numbers are chosen for the number of buckets in tandem with sophisticated modulo arithmetic. This removes the need for "mixing" the result of the user's hash function as was used for release 1.79.0.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">73</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="773966b40c2979b2" weblate-flags="read-only, safe-html, strict-same">
        <source>Open-addresing Containers</source>
        <target state="translated">Open-addresing Containers</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">77</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c792cb4cacc55af7" weblate-flags="read-only, safe-html, strict-same">
        <source>The C++ standard specification of unordered associative containers impose severe limitations on permissible implementations, the most important being that closed addressing is implicitly assumed. Slightly relaxing this specification opens up the possibility of providing container variations taking full advantage of open-addressing techniques.</source>
        <target state="translated">The C++ standard specification of unordered associative containers impose severe limitations on permissible implementations, the most important being that closed addressing is implicitly assumed. Slightly relaxing this specification opens up the possibility of providing container variations taking full advantage of open-addressing techniques.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">79</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6927df3de28ca1f7" weblate-flags="read-only, safe-html, strict-same">
        <source>The design of `boost::unordered_flat_set`/`unordered_node_set` and `boost::unordered_flat_map`/`unordered_node_map` has been guided by Peter Dimov's https://pdimov.github.io/articles/unordered_dev_plan.html[Development Plan for Boost.Unordered^]. We discuss here the most relevant principles.</source>
        <target state="translated">The design of `boost::unordered_flat_set`/`unordered_node_set` and `boost::unordered_flat_map`/`unordered_node_map` has been guided by Peter Dimov's https://pdimov.github.io/articles/unordered_dev_plan.html[Development Plan for Boost.Unordered^]. We discuss here the most relevant principles.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">85</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="08928517f1d814f3" weblate-flags="read-only, safe-html, strict-same">
        <source>Hash Function</source>
        <target state="translated">Hash Function</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">89</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4db2097bcfd76b32" weblate-flags="read-only, safe-html, strict-same">
        <source>Given its rich functionality and cross-platform interoperability, `boost::hash` remains the default hash function of open-addressing containers. As it happens, `boost::hash` for integral and other basic types does not possess the statistical properties required by open addressing; to cope with this, we implement a post-mixing stage:</source>
        <target state="translated">Given its rich functionality and cross-platform interoperability, `boost::hash` remains the default hash function of open-addressing containers. As it happens, `boost::hash` for integral and other basic types does not possess the statistical properties required by open addressing; to cope with this, we implement a post-mixing stage:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">91</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e366bcc75e6e7022" weblate-flags="read-only, safe-html, strict-same">
        <source>{nbsp}{nbsp}{nbsp}{nbsp} _a_ &lt;- _h_ *mul* _C_, + {nbsp}{nbsp}{nbsp}{nbsp} _h_ &lt;- *high*(_a_) *xor* *low*(_a_),</source>
        <target state="translated">{nbsp}{nbsp}{nbsp}{nbsp} _a_ &lt;- _h_ *mul* _C_, + {nbsp}{nbsp}{nbsp}{nbsp} _h_ &lt;- *high*(_a_) *xor* *low*(_a_),</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">97</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3c16f9f2119db453" weblate-flags="read-only, safe-html, strict-same">
        <source>where *mul* is an _extended multiplication_ (128 bits in 64-bit architectures, 64 bits in 32-bit environments), and *high* and *low* are the upper and lower halves of an extended word, respectively. In 64-bit architectures, _C_ is the integer part of 2^64^&amp;#8725;https://en.wikipedia.org/wiki/Golden_ratio[_&amp;phi;_], whereas in 32 bits _C_ = 0xE817FB2Du has been obtained from https://arxiv.org/abs/2001.05304[Steele and Vigna (2021)^].</source>
        <target state="translated">where *mul* is an _extended multiplication_ (128 bits in 64-bit architectures, 64 bits in 32-bit environments), and *high* and *low* are the upper and lower halves of an extended word, respectively. In 64-bit architectures, _C_ is the integer part of 2^64^&amp;#8725;https://en.wikipedia.org/wiki/Golden_ratio[_&amp;phi;_], whereas in 32 bits _C_ = 0xE817FB2Du has been obtained from https://arxiv.org/abs/2001.05304[Steele and Vigna (2021)^].</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">100</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ca0c157871513af4" weblate-flags="read-only, safe-html, strict-same">
        <source>When using a hash function directly suitable for open addressing, post-mixing can be opted out of via a dedicated `link:../../../../container_hash/doc/html/hash.html#ref_hash_is_avalanchinghash[hash_is_avalanching]` trait. `boost::hash` specializations for string types are marked as avalanching.</source>
        <target state="translated">When using a hash function directly suitable for open addressing, post-mixing can be opted out of via a dedicated `link:../../../../container_hash/doc/html/hash.html#ref_hash_is_avalanchinghash[hash_is_avalanching]` trait. `boost::hash` specializations for string types are marked as avalanching.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">105</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c4cb47de975f6431" weblate-flags="read-only, safe-html, strict-same">
        <source>Platform Interoperability</source>
        <target state="translated">Platform Interoperability</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">109</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5fd7f432f4347390" weblate-flags="read-only, safe-html, strict-same">
        <source>The observable behavior of `boost::unordered_flat_set`/`unordered_node_set` and `boost::unordered_flat_map`/`unordered_node_map` is deterministically identical across different compilers as long as their ``std::size_t``s are the same size and the user-provided hash function and equality predicate are also interoperable —this includes elements being ordered in exactly the same way for the same sequence of operations.</source>
        <target state="translated">The observable behavior of `boost::unordered_flat_set`/`unordered_node_set` and `boost::unordered_flat_map`/`unordered_node_map` is deterministically identical across different compilers as long as their ``std::size_t``s are the same size and the user-provided hash function and equality predicate are also interoperable —this includes elements being ordered in exactly the same way for the same sequence of operations.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">111</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b4bc9f8b2953ad93" weblate-flags="read-only, safe-html, strict-same">
        <source>Although the implementation internally uses SIMD technologies, such as https://en.wikipedia.org/wiki/SSE2[SSE2^] and https://en.wikipedia.org/wiki/ARM_architecture_family#Advanced_SIMD_(NEON)[Neon^], when available, this does not affect interoperatility. For instance, the behavior is the same for Visual Studio on an x64-mode Intel CPU with SSE2 and for GCC on an IBM s390x without any supported SIMD technology.</source>
        <target state="translated">Although the implementation internally uses SIMD technologies, such as https://en.wikipedia.org/wiki/SSE2[SSE2^] and https://en.wikipedia.org/wiki/ARM_architecture_family#Advanced_SIMD_(NEON)[Neon^], when available, this does not affect interoperatility. For instance, the behavior is the same for Visual Studio on an x64-mode Intel CPU with SSE2 and for GCC on an IBM s390x without any supported SIMD technology.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">117</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f8a981fd33bbaba5" weblate-flags="read-only, safe-html, strict-same">
        <source>Concurrent Containers</source>
        <target state="translated">Concurrent Containers</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">122</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="646b167a614f5039" weblate-flags="read-only, safe-html, strict-same">
        <source>The same data structure used by Boost.Unordered open-addressing containers has been chosen also as the foundation of `boost::concurrent_flat_set`/`boost::concurrent_node_set` and `boost::concurrent_flat_map`/`boost::concurrent_node_map`:</source>
        <target state="translated">The same data structure used by Boost.Unordered open-addressing containers has been chosen also as the foundation of `boost::concurrent_flat_set`/`boost::concurrent_node_set` and `boost::concurrent_flat_map`/`boost::concurrent_node_map`:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">124</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="fd0048713089200c" weblate-flags="read-only, safe-html, strict-same">
        <source>Open-addressing is faster than closed-addressing alternatives, both in non-concurrent and</source>
        <target state="translated">Open-addressing is faster than closed-addressing alternatives, both in non-concurrent and</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">128</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e11895f317e5c481" weblate-flags="read-only, safe-html, strict-same">
        <source>concurrent scenarios.</source>
        <target state="translated">concurrent scenarios.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">129</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="eef9663c3102cba6" weblate-flags="read-only, safe-html, strict-same">
        <source>Open-addressing layouts are eminently suitable for concurrent access and modification</source>
        <target state="translated">Open-addressing layouts are eminently suitable for concurrent access and modification</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">130</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="bf1775093b143561" weblate-flags="read-only, safe-html, strict-same">
        <source>with minimal locking. In particular, the metadata array can be used for implementations of lookup that are lock-free up to the last step of actual element comparison.</source>
        <target state="translated">with minimal locking. In particular, the metadata array can be used for implementations of lookup that are lock-free up to the last step of actual element comparison.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">131</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c6e3503bcd22fef1" weblate-flags="read-only, safe-html, strict-same">
        <source>Layout compatibility with Boost.Unordered flat containers allows for</source>
        <target state="translated">Layout compatibility with Boost.Unordered flat containers allows for</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">133</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="dbe1c8d8b9dffcbe" weblate-flags="read-only, safe-html, strict-same">
        <source>xref:concurrent.adoc#concurrent_interoperability_with_non_concurrent_containers[fast transfer] of all elements between a concurrent container and its non-concurrent counterpart, and vice versa.</source>
        <target state="translated">xref:concurrent.adoc#concurrent_interoperability_with_non_concurrent_containers[fast transfer] of all elements between a concurrent container and its non-concurrent counterpart, and vice versa.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">134</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2912ac45864638ec" weblate-flags="read-only, safe-html, strict-same">
        <source>Hash Function and Platform Interoperability</source>
        <target state="translated">Hash Function and Platform Interoperability</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">138</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f5b2a87027eb621e" weblate-flags="read-only, safe-html, strict-same">
        <source>Concurrent containers make the same decisions and provide the same guarantees as Boost.Unordered open-addressing containers with regards to xref:#rationale_hash_function[hash function defaults] and xref:#rationale_platform_interoperability[platform interoperability].</source>
        <target state="translated">Concurrent containers make the same decisions and provide the same guarantees as Boost.Unordered open-addressing containers with regards to xref:#rationale_hash_function[hash function defaults] and xref:#rationale_platform_interoperability[platform interoperability].</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">140</context>
        </context-group>
      </trans-unit>
    </body>
  </file>
</xliff>
