editorial

This commit is contained in:
joaquintides 2023-02-18 12:13:14 +01:00
parent aa6eef135e
commit d0289b4c7b
3 changed files with 8 additions and 7 deletions

View File

@ -262,7 +262,7 @@ The diagram shows the basic internal layout of `boost::unordered_flat_map`/`unor
.Open-addressing layout used by Boost.Unordered. .Open-addressing layout used by Boost.Unordered.
image::foa.png[align=center] image::foa.png[align=center]
As with all open-addressing containers, elements (or element nodes in the case of As with all open-addressing containers, elements (or pointers to the element nodes in the case of
`boost::unordered_node_map` and `boost::unordered_node_set`) are stored directly in the bucket array. `boost::unordered_node_map` and `boost::unordered_node_set`) are stored directly in the bucket array.
This array is logically divided into 2^_n_^ _groups_ of 15 elements each. This array is logically divided into 2^_n_^ _groups_ of 15 elements each.
In addition to the bucket array, there is an associated _metadata array_ with 2^_n_^ In addition to the bucket array, there is an associated _metadata array_ with 2^_n_^

View File

@ -5,9 +5,9 @@
:cpp: C++ :cpp: C++
== Closed-addressing containers: unordered_[multi]set, unordered_[multi]map == Closed-addressing containers
The intent of Boost.Unordered is to provide a conformant `unordered_[multi]set` and `unordered_[multi]map` are intended to provide a conformant
implementation of the {cpp}20 standard that will work with {cpp}98 upwards. implementation of the {cpp}20 standard that will work with {cpp}98 upwards.
This wide compatibility does mean some compromises have to be made. This wide compatibility does mean some compromises have to be made.
With a compiler and library that fully support {cpp}11, the differences should With a compiler and library that fully support {cpp}11, the differences should
@ -117,7 +117,7 @@ Variadic constructor arguments for `emplace` are only used when both
rvalue references and variadic template parameters are available. rvalue references and variadic template parameters are available.
Otherwise `emplace` can only take up to 10 constructors arguments. Otherwise `emplace` can only take up to 10 constructors arguments.
== Open-addressing containers: unordered_flat_set/unordered_node_set, unordered_flat_map/unordered_node_map == Open-addressing containers
The C++ standard does not currently provide any open-addressing container The C++ standard does not currently provide any open-addressing container
specification to adhere to, so `boost::unordered_flat_set`/`unordered_node_set` and specification to adhere to, so `boost::unordered_flat_set`/`unordered_node_set` and

View File

@ -4,9 +4,10 @@
= Implementation Rationale = Implementation Rationale
== boost::unordered_[multi]set and boost::unordered_[multi]map == Closed-addressing containers
These containers adhere to the standard requirements for unordered associative `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 containers, so the interface was fixed. But there are
still some implementation decisions to make. The priorities are still some implementation decisions to make. The priorities are
conformance to the standard and portability. conformance to the standard and portability.
@ -73,7 +74,7 @@ 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" 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. the result of the user's hash function as was used for release 1.79.0.
== boost::unordered_flat_set/unordered_node_set and boost::unordered_flat_map/unordered_node_map == Open-addresing containers
The C++ standard specification of unordered associative containers impose The C++ standard specification of unordered associative containers impose
severe limitations on permissible implementations, the most important being severe limitations on permissible implementations, the most important being