<?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="zh_Hans">
    <body>
      <trans-unit xml:space="preserve" approved="no" id="c9c8cde85ce1e43b" weblate-flags="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="safe-html, strict-same">
        <source>= Implementation Rationale</source>
        <target state="translated">= 实现设计依据</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="safe-html, strict-same">
        <source>Closed-addressing Containers</source>
        <target state="translated">闭寻址容器</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="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` 与 `boost::unordered++_[++multi++]++map` 遵循无序关联容器的标准规范，因此其接口是确定的。但在实现层面仍需做出一些决策，其首要考量是标准符合性与跨平台移植性。</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="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">关于哈希表的通用实现问题的详细综述，可参阅 http://en.wikipedia.org/wiki/Hash_table[维基百科哈希表条目] 。</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="safe-html, strict-same">
        <source>Data Structure</source>
        <target state="translated">数据结构</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="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">通过制定用于访问容器桶的接口，该标准实质上要求哈希表必须采用闭寻址方案。</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="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">理论上完全可以设计采用其他实现方式的哈希表。例如，采用开放寻址法，利用查找链来模拟桶的行为，但这种做法会带来一些严重问题：</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="safe-html, strict-same">
        <source>The standard requires that pointers to elements aren't invalidated, so</source>
        <target state="translated">该标准要求指向元素的指针不得失效，因此</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="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">元素无法存储在一个连续的数组中，而需要增加一层间接寻址——这将损失开放定址法的主要优势，即效率和大部分内存收益。</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="safe-html, strict-same">
        <source>Local iterators would be very inefficient and may not be able to</source>
        <target state="translated">局部迭代器的实现将极为低效，且可能无法</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="safe-html, strict-same">
        <source>meet the complexity requirements.</source>
        <target state="translated">满足复杂度要求。</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="safe-html, strict-same">
        <source>There are also the restrictions on when iterators can be invalidated. Since</source>
        <target state="translated">此外，标准对迭代器失效的时机也存在限制。由于</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="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">开放寻址法在发生大量冲突时性能会急剧下降，这些限制可能会阻止必要的重新哈希操作。虽然可以通过设置较低的最大负载因子来规避此问题——但标准要求该值初始必须设为 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="safe-html, strict-same">
        <source>And since the standard is written with a eye towards closed</source>
        <target state="translated">由于该标准的制定主要着眼于闭寻址方案，</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="safe-html, strict-same">
        <source>addressing, users will be surprised if the performance doesn't reflect that.</source>
        <target state="translated">若性能表现不符预期，将会引发用户的困惑。</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="safe-html, strict-same">
        <source>So closed addressing is used.</source>
        <target state="translated">因此采用闭寻址方式。</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="safe-html, strict-same">
        <source>Number of Buckets</source>
        <target state="translated">桶数量</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="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">选择哈希表桶数量有两种主流方法：一种是采用质数作为桶的数量，另一种则是使用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="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">使用质数数量的桶，并通过哈希函数结果取模来选择桶，通常能获得良好的分布效果。其缺点在于所需的取模运算开销较大。这是该容器在大多数情况下之前的做法。</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="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">使用2的幂次方可加快桶选择速度，但代价是牺牲哈希值的高位比特。对于一些特殊设计的哈希函数，这样做仍能获得良好效果，但由于容器需要兼容任意哈希函数，因此不能依赖这种方法。</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="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">为避免此问题，可对哈希函数施加转换操作（具体示例可参阅 http://web.archive.org/web/20121102023700/http://www.concentric.net/~Ttwang/tech/inthash.htm[Thomas Wang整数哈希函数文章]）。但此类变换需知晓哈希值比特数，故仅在 `size++_++t` 为64位时才会启用。</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="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">自1.79.0版起，改用 https://en.wikipedia.org/wiki/Hash_function#Fibonacci_hashing[斐波那契哈希] 。在此实现中，桶编号通过公式 `(h * m) &gt;&gt; (w - k)` 确定：其中 `h` 为哈希值， `m` 为 `2^w` 除以黄金分割比的值， `w` 为字长（32位或64位）， `2^k` 表示桶的数量。此方法在速度和分布均匀性之间实现了较好的平衡。</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="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">自1.80.0版起，结合精密取模运算选用质数桶量，无需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="safe-html, strict-same">
        <source>Open-addresing Containers</source>
        <target state="translated">开地址容器</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="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">C++ 标准中对无序关联容器的规范对允许的实现方式施加了严格的限制，其中最重要的一点是隐式假定使用闭地址法。稍微放宽这一规范，则为提供能够充分利用开放寻址技术的容器变体开辟了可能性。</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="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">`boost::unordered++_++flat++_++set` / `unordered++_++node++_++set` 及 `boost::unordered++_++flat++_++map` / `unordered++_++node++_++map` 的设计遵循Peter Dimov的 https://pdimov.github.io/articles/unordered_dev_plan.html[Boost.Unordered开发计划] 中提出的指导原则。下文将探讨其中最核心的设计理念。</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="safe-html, strict-same">
        <source>Hash Function</source>
        <target state="translated">哈希函数</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="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">基于其丰富功能与跨平台互操作性， `boost::hash` 仍是开放寻址容器的默认哈希函数。但由于其对整型等基础类型实现的 boost::hash 缺乏开放寻址所需的统计特性，我们额外增加了后混合处理阶段：</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="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_ &amp;lt;- _h_ *mul* _C_, + {nbsp}{nbsp}{nbsp}{nbsp} _h_ &amp;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="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">其中 *mul* 是 _扩展乘法_（64 位架构中为 128 位，32 位环境中为 64 位），*high* 和 *low* 分别表示扩展字的高位部分和低位部分。在 64 位架构中，_C_ 是 2^64^∕https://en.wikipedia.org/wiki/Golden_ratio[_φ_] 的整数部分；而在 32 位架构中，_C_ = 0xE817FB2Du 取自 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="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">当使用直接适合开放定址的哈希函数时，可以通过专用的 `link:../../../../container_hash/doc/html/hash.html#ref_hash_is_avalanching[hash_is_avalanching]` 特征来退出后混合操作。针对字符串类型的 `boost::hash` 特化已被标记为雪崩式哈希。</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="safe-html, strict-same">
        <source>Platform Interoperability</source>
        <target state="translated">平台互操作性</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="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">只要不同编译器中的 `std::size_t` 大小相同，并且用户提供的哈希函数和相等谓词也具有互操作性，那么 `boost::unordered_flat_set`/`unordered_node_set` 和 `boost::unordered_flat_map`/`unordered_node_map` 的可观测行为在不同编译器之间是确定相同的——这包括对于相同的操作序列，元素的排列顺序也完全相同。</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="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">尽管实现内部在可用时会使用 SIMD 技术，例如 https://en.wikipedia.org/wiki/SSE2[SSE2^] 和 https://en.wikipedia.org/wiki/ARM_architecture_family#Advanced_SIMD_(NEON)[Neon^]，但这并不影响互操作性。例如，在带有 SSE2 的 x64 模式 Intel CPU 上使用 Visual Studio 的行为，与在不支持任何 SIMD 技术的 IBM s390x 上使用 GCC 的行为相同。</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="safe-html, strict-same">
        <source>Concurrent Containers</source>
        <target state="translated">并发容器</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="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">Boost.Unordered 开放寻址容器所使用的相同数据结构也被选为 `boost::concurrent_flat_set`/`boost::concurrent_node_set` 和 `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="safe-html, strict-same">
        <source>Open-addressing is faster than closed-addressing alternatives, both in non-concurrent and</source>
        <target state="translated">无论是在非并发环境还是并发环境下，开放寻址都比闭地址方案更快。</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="safe-html, strict-same">
        <source>concurrent scenarios.</source>
        <target state="translated">并发场景中也是如此。</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="safe-html, strict-same">
        <source>Open-addressing layouts are eminently suitable for concurrent access and modification</source>
        <target state="translated">开放寻址的内存布局极其适合在最小化锁竞争的条件下进行并发访问与修改。</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="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">通过最小化锁定。特别是，元数据数组可用于实现查找操作，该操作在实际元素比较的最后一步之前都是无锁的。</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="safe-html, strict-same">
        <source>Layout compatibility with Boost.Unordered flat containers allows for</source>
        <target state="translated">并发容器与 Boost.Unordered 扁平容器具有</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="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[快速双向传输] 所有元素。</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="safe-html, strict-same">
        <source>Hash Function and Platform Interoperability</source>
        <target state="translated">哈希函数与平台互操作性</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="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">在 xref:#rationale_hash_function[哈希函数默认值] 和 xref:#rationale_platform_interoperability[平台互操作性] 方面，并发容器与 Boost.Unordered 开放寻址容器做出了相同的决策并提供了相同的保证。</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">140</context>
        </context-group>
      </trans-unit>
    </body>
  </file>
</xliff>
