feedc0de/boost_unordered
1
0
Fork 0
forked from boostorg/unordered
Code Pull Requests Activity

Add some notes on the active issues relevant to the unordered associative

Browse Source 
containers.


[SVN r2922]
This commit is contained in:
Daniel James
2006-04-17 10:54:02 +00:00
parent e8faab1268
commit c243c3d5c1
1 changed files with 34 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
doc/rationale.qbk
View File

@@ -27,4 +27,38 @@ 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, 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?). 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] [endsect]