boostorg/unordered
1
0
Fork 1
mirror of https://github.com/boostorg/unordered.git synced 2025-07-31 11:57:15 +02:00
Code Issues Packages Projects Releases Wiki Activity

Try to make the active issues and proposals a little clearer - including more obvious links to the relevant papers.

Browse Source 
[SVN r42098]
This commit is contained in:
Daniel James
2007-12-16 10:47:13 +00:00
parent 27f40410c1
commit 10b6f40fa5
1 changed files with 24 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

38
doc/rationale.qbk
View File

@@ -98,33 +98,43 @@ So, this implementation uses a prime number for the hash table size.
[h2 Active Issues and Proposals] [h2 Active Issues and Proposals]
[h3 [@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html [h3 Removing unused allocator functions]
Removing unused allocator functions]]
This proposal suggests removing the `construct`, `destroy` and `address` In
member functions - all of which Boost.Unordered calls. It's near trivial [@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html
to replace the calls with the appropriate code - and will simplify the N2257, removing unused allocator functions],
implementation, as well as make supporting `emplace` easier. Matt Austern suggests removing the `construct`, `destroy` and `address` member
[@http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2339.htm functions - all of which Boost.Unordered calls. Changing this will simplify the
N2339] opposed this change. implementation, as well as make supporting `emplace` easier, but means that the
containers won't support allocators which require these methods to be called.
Detlef Vollmann opposed this change in
[@http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2339.htm N2339].
[h3 [@http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#431 [h3 Swapping containers with unequal allocators]
431. Swapping containers with unequal allocators]]
I followed Howard Hinnant's advice and implemented option 3. It isn't clear how to swap containers when their allocators aren't equal.
This is
[@http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#431
Issue 431: Swapping containers with unequal allocators].
Howard Hinnant wrote about this in
[@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1599.html N1599]
and suggested swapping both the allocators and the containers' contents.
There is currently a further issue - if the allocator's swap does throw there's There is currently a further issue - if the allocator's swap does throw there's
no guarantee what state the allocators will be in. The only solution seems to no guarantee what state the allocators will be in. The only solution seems to
be to double buffer the allocators. But I'm assuming that it won't throw for now. be to double buffer the allocators. But I'm assuming that it won't throw for
now.
Update: The committee have now decided that `swap` should do a fast swap if the Update: The committee have now decided that `swap` should do a fast swap if the
allocator is Swappable and a slow swap using copy construction otherwise. To allocator is Swappable and a slow swap using copy construction otherwise. To
make this distinction requires concepts. For now I'm sticking with the current make this distinction requires concepts. For now I'm sticking with the current
implementation. implementation.
[h3 [@http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518 [h3 Are insert and erase stable for unordered_multiset and unordered_multimap?]
518. Are insert and erase stable for unordered_multiset and unordered_multimap?]]
It is not specified if `unordered_multiset` and `unordered_multimap` preserve the order
of elements with equivalent keys (i.e. if they're stable under `insert` and `erase`).
This is [@http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518 issue 581].
The current proposal is that insert, erase and rehash are stable - so they are here. The current proposal is that insert, erase and rehash are stable - so they are here.
[h2 Future Developments] [h2 Future Developments]