forked from boostorg/unordered
65 lines
3.0 KiB
Plaintext
65 lines
3.0 KiB
Plaintext
[def __wang__
|
|
[@http://www.concentric.net/~Ttwang/tech/inthash.htm
|
|
Thomas Wang's article on integer hash functions]]
|
|
|
|
[section:rationale Implementation Rationale]
|
|
|
|
From the start the intent of this library was to implement the unordred
|
|
containers in TR1, so the interface was fixed. But there are still some
|
|
implementation desicions to make. The priorities for the library are
|
|
conformance to the standard and portability.
|
|
|
|
[h2 Number of Buckets]
|
|
|
|
There are two popular methods for choosing the number of buckets in a hash
|
|
table. One is to have a prime number of buckets. This allows .... (TODO)
|
|
|
|
The other is to always use a power of two. This has a potential efficiency
|
|
advantage, since it avoids the costly modulus calculation. It also allows for ... (TODO)
|
|
|
|
For a power of two hash table to work the hash values need to be
|
|
evenly distributed for the subset of the bits it is going to use - and since
|
|
the container can take an arbitrary hash function it must do this itself.
|
|
For some methods for doing this see __wang__ (TODO: Other references?).
|
|
Unfortunately, the most effective methods require the input to be an integer
|
|
with a certain number of bits, while ``std::size_t`` can have an arbitrary
|
|
range. This leaves the more expensive methods, such as Knuth's Multiplicative
|
|
Method which don't tend to work as well as taking the modulous of a prime,
|
|
have little efficiency advantage and don't work well for (TODO: what are they called?).
|
|
|
|
[h2 Active Issues]
|
|
|
|
[h3 [@http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#258
|
|
258. Missing allocator requirement]]
|
|
|
|
Need to look into this one.
|
|
|
|
[h3 [@http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#431
|
|
431. Swapping containers with unequal allocators]]
|
|
|
|
In a fit of probably unwise enthusiasm, I implemented all the three versions
|
|
with a macro (BOOST_UNORDERED_SWAP_METHOD) to pick which one is used. As
|
|
suggested by Howard Hinnant, I set option 3 as the default. I'll probably remove
|
|
the alternative implementations before review.
|
|
|
|
[h3 [@http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518
|
|
518. Are insert and erase stable for unordered_multiset and unordered_multimap?]]
|
|
|
|
In this implementation, erase is stable but insert is not. As long as a rehash
|
|
can change the order of the elements, insert can't be.
|
|
|
|
[h3 [@http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#528
|
|
528. TR1: issue 6.19 vs 6.3.4.3/2 (and 6.3.4.5/2)]]
|
|
|
|
In the current implementation, for unordered_set and
|
|
unordered_multiset, iterator and const_iterator have the same type and
|
|
local_iterator and const_local_iterator also have the same type. This makes it
|
|
impossible to implement the header exactly as described in the synopsis, as
|
|
some member functions are overloaded by the same type.
|
|
According to the proposed resolution,
|
|
[:If they are the same type, those signatures that become otherwise indistinguishable collapse into a single signature.]
|
|
So I'm following that - although this means that the header and documentation
|
|
are currently inconsistent. This will be fixed before review submission.
|
|
|
|
[endsect]
|