Boost Unordered Translation (zh_Hans)/Doc / Modules / Root / Pages / Rationale (adoc) — Chinese (Simplified Han script) @ Boost-Weblate: Layout compatibility with Boost.Unordered flat containers allows for

Zen

Translation

English

Chinese (Simplified Han script)

Needs editing

Skip

	English	Chinese (Simplified Han script)	Actions
	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.	`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开发计划] 中提出的指导原则。下文将探讨其中最核心的设计理念。
	Hash Function	哈希函数
	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:	基于其丰富功能与跨平台互操作性， `boost::hash` 仍是开放寻址容器的默认哈希函数。但由于其对整型等基础类型实现的 boost::hash 缺乏开放寻址所需的统计特性，我们额外增加了后混合处理阶段：
	{nbsp}{nbsp}{nbsp}{nbsp} _a_ <- _h_ mul _C_, + {nbsp}{nbsp}{nbsp}{nbsp} _h_ <- high(_a_) xor low(_a_),	{nbsp}{nbsp}{nbsp}{nbsp} _a_ <- _h_ mul _C_, + {nbsp}{nbsp}{nbsp}{nbsp} _h_ <- high(_a_) xor low(_a_),
	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^∕https://en.wikipedia.org/wiki/Golden_ratio[_φ_], whereas in 32 bits _C_ = 0xE817FB2Du has been obtained from https://arxiv.org/abs/2001.05304[Steele and Vigna (2021)^].	其中 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)^]。
	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.	当使用直接适合开放定址的哈希函数时，可以通过专用的 `link:../../../../container_hash/doc/html/hash.html#ref_hash_is_avalanching[hash_is_avalanching]` 特征来退出后混合操作。针对字符串类型的 `boost::hash` 特化已被标记为雪崩式哈希。
	Platform Interoperability	平台互操作性
	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.	只要不同编译器中的 `std::size_t` 大小相同，并且用户提供的哈希函数和相等谓词也具有互操作性，那么 `boost::unordered_flat_set`/`unordered_node_set` 和 `boost::unordered_flat_map`/`unordered_node_map` 的可观测行为在不同编译器之间是确定相同的——这包括对于相同的操作序列，元素的排列顺序也完全相同。
	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.	尽管实现内部在可用时会使用 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 的行为相同。
	Concurrent Containers	并发容器
	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`:	Boost.Unordered 开放寻址容器所使用的相同数据结构也被选为 `boost::concurrent_flat_set`/`boost::concurrent_node_set` 和 `boost::concurrent_flat_map`/`boost::concurrent_node_map` 的基础：
	Open-addressing is faster than closed-addressing alternatives, both in non-concurrent and	无论是在非并发环境还是并发环境下，开放寻址都比闭地址方案更快。
	concurrent scenarios.	并发场景中也是如此。
	Open-addressing layouts are eminently suitable for concurrent access and modification	开放寻址的内存布局极其适合在最小化锁竞争的条件下进行并发访问与修改。
	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.	通过最小化锁定。特别是，元数据数组可用于实现查找操作，该操作在实际元素比较的最后一步之前都是无锁的。
	Layout compatibility with Boost.Unordered flat containers allows for	并发容器与 Boost.Unordered 扁平容器具有
	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.	内存布局兼容性，支持其与非并发对应容器之间 xref:concurrent.adoc#concurrent_interoperability_with_non_concurrent_containers[快速双向传输] 所有元素。
	Hash Function and Platform Interoperability	哈希函数与平台互操作性
	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].	在 xref:#rationale_hash_function[哈希函数默认值] 和 xref:#rationale_platform_interoperability[平台互操作性] 方面，并发容器与 Boost.Unordered 开放寻址容器做出了相同的决策并提供了相同的保证。

	English	Chinese (Simplified Han script)	Actions
	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) >> (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.	自1.79.0版起，改用 https://en.wikipedia.org/wiki/Hash_function#Fibonacci_hashing[斐波那契哈希] 。在此实现中，桶编号通过公式 `(h * m) >> (w - k)` 确定：其中 `h` 为哈希值， `m` 为 `2^w` 除以黄金分割比的值， `w` 为字长（32位或64位）， `2^k` 表示桶的数量。此方法在速度和分布均匀性之间实现了较好的平衡。
	Open-addresing Containers	开地址容器
	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.	C++ 标准中对无序关联容器的规范对允许的实现方式施加了严格的限制，其中最重要的一点是隐式假定使用闭地址法。稍微放宽这一规范，则为提供能够充分利用开放寻址技术的容器变体开辟了可能性。
	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.	`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开发计划] 中提出的指导原则。下文将探讨其中最核心的设计理念。
	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:	基于其丰富功能与跨平台互操作性， `boost::hash` 仍是开放寻址容器的默认哈希函数。但由于其对整型等基础类型实现的 boost::hash 缺乏开放寻址所需的统计特性，我们额外增加了后混合处理阶段：
	{nbsp}{nbsp}{nbsp}{nbsp} _a_ <- _h_ mul _C_, + {nbsp}{nbsp}{nbsp}{nbsp} _h_ <- high(_a_) xor low(_a_),	{nbsp}{nbsp}{nbsp}{nbsp} _a_ <- _h_ mul _C_, + {nbsp}{nbsp}{nbsp}{nbsp} _h_ <- high(_a_) xor low(_a_),
	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^∕https://en.wikipedia.org/wiki/Golden_ratio[_φ_], whereas in 32 bits _C_ = 0xE817FB2Du has been obtained from https://arxiv.org/abs/2001.05304[Steele and Vigna (2021)^].	其中 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)^]。
	Platform Interoperability	平台互操作性
	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.	只要不同编译器中的 `std::size_t` 大小相同，并且用户提供的哈希函数和相等谓词也具有互操作性，那么 `boost::unordered_flat_set`/`unordered_node_set` 和 `boost::unordered_flat_map`/`unordered_node_map` 的可观测行为在不同编译器之间是确定相同的——这包括对于相同的操作序列，元素的排列顺序也完全相同。
	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.	尽管实现内部在可用时会使用 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 的行为相同。
	Concurrent Containers	并发容器
	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`:	Boost.Unordered 开放寻址容器所使用的相同数据结构也被选为 `boost::concurrent_flat_set`/`boost::concurrent_node_set` 和 `boost::concurrent_flat_map`/`boost::concurrent_node_map` 的基础：
	concurrent scenarios.	并发场景中也是如此。
	Open-addressing layouts are eminently suitable for concurrent access and modification	开放寻址的内存布局极其适合在最小化锁竞争的条件下进行并发访问与修改。
	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.	通过最小化锁定。特别是，元数据数组可用于实现查找操作，该操作在实际元素比较的最后一步之前都是无锁的。
	Layout compatibility with Boost.Unordered flat containers allows for	并发容器与 Boost.Unordered 扁平容器具有
	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.	内存布局兼容性，支持其与非并发对应容器之间 xref:concurrent.adoc#concurrent_interoperability_with_non_concurrent_containers[快速双向传输] 所有元素。
	Hash Function and Platform Interoperability	哈希函数与平台互操作性

Loading…

admin

Translation uploaded

English

Chinese (Simplified Han script) 51 characters editedCurrent translationState: Translated

06/05/2026

admin

String added in the repository

English

Chinese (Simplified Han script) 68 characters editedPrevious translationState: Needs editing (Needs rewriting)

06/05/2026

Browse all string changes

Glossary

English	Chinese (Simplified Han script)
No related strings found in the glossary.

String information

Flags

safe-html, strict-same

Unit identifier

50832

Source string location

:133

String age

06/05/2026

Last updated

06/06/2026

Source string age

06/05/2026

Translation file AsciiDoc file

doc/modules/ROOT/pages/rationale_zh_Hans.adoc, string 42

Shortcut	Action
`?`	Open available keyboard shortcuts.
`Alt` + `Home`	Navigate to the first translation in the current search.
`Alt` + `End`	Navigate to the last translation in the current search.
`Alt` + `PageUp` or `Ctrl` + `↑` or `Alt` + `↑` or `Cmd` + `↑` or	Navigate to the previous translation in the current search.
`Alt` + `PageDown` or `Ctrl` + `↓` or `Alt` + `↓` or `Cmd` + `↓` or	Navigate to the next translation in the current search.
`Ctrl` + `Enter` or `Cmd` + `Enter`	Submit current form; this works the same as pressing Save and continue while editing translation.
`Ctrl` + `Shift` + `Enter` or `Cmd` + `Shift` +`Enter`	Unmark translation as Needing edit and submit it.
`Alt` + `Enter` or `Option` + `Enter`	Submit the string as a suggestion; this works the same as pressing Suggest while editing translation.
`Ctrl` + `E` or `Cmd` + `E`	Focus on translation editor.
`Ctrl` + `U` or `Cmd` + `U`	Focus on comment editor.
`Ctrl` + `M` or `Cmd` + `M`	Shows Automatic suggestions tab.
`Ctrl` + `1` to `Ctrl` + `9` or `Cmd` + `1` to `Cmd` + `9`	Copies placeable of a given number from source string.
`Ctrl` + `M` followed by `1` to `9` or `Cmd` + `M` followed by `1` to `9`	Copy the machine translation of a given number to current translation.
`Ctrl` + `I` followed by `1` to `9` or `Cmd` + `I` followed by `1` to `9`	Ignore one item in the list of failing checks.
`Ctrl` + `J` or `Cmd` + `J`	Shows the Nearby strings tab.
`Ctrl` + `S` or `Cmd` + `S`	Focus on search field.
`Ctrl` + `O` or `Cmd` + `O`	Copy the source string.
`Ctrl` + `Y` or `Cmd` + `Y`	Toggle the Needs editing checkbox.
`→`	Browse the next translation string.
`←`	Browse the previous translation string.

Translation

Glossary

String information

Flags

Details

Unit identifier

Source string location

String age

Last updated

Source string age

Translation file AsciiDoc file