From c243c3d5c11f520549cb3d40d8d8c364d2f47a31 Mon Sep 17 00:00:00 2001 From: Daniel James Date: Mon, 17 Apr 2006 10:54:02 +0000 Subject: [PATCH] Add some notes on the active issues relevant to the unordered associative containers. [SVN r2922] --- doc/rationale.qbk | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/doc/rationale.qbk b/doc/rationale.qbk index 9740c192..fe92c256 100644 --- a/doc/rationale.qbk +++ b/doc/rationale.qbk @@ -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, 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]