[Boost-commit] svn:boost r4145

From: danieljames_at_[hidden]
Date: 2007-05-20 12:48:53

Author: danieljames
Date: 2007-05-20 12:48:52 EDT (Sun, 20 May 2007)
New Revision: 4145
URL: http://svn.boost.org/trac/boost/changeset/4145

Log:
Add a couple of notes about the updated issues/proposals in the post-Oxford mailing (more to come...)

Text files modified: 
   sandbox/unordered/libs/unordered/doc/rationale.qbk |    19 ++++++++++++++-----                     
   1 files changed, 14 insertions(+), 5 deletions(-)

Modified: sandbox/unordered/libs/unordered/doc/rationale.qbk
==============================================================================
--- sandbox/unordered/libs/unordered/doc/rationale.qbk	(original)
+++ sandbox/unordered/libs/unordered/doc/rationale.qbk	2007-05-20 12:48:52 EDT (Sun, 20 May 2007)
@@ -90,22 +90,31 @@
 
 So, this implementation uses a prime number for the hash table size.
 
-[h2 Active Issues]
+[h2 Active Issues and Proposals]
 
-[h3 [@http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#258
-    258. Missing allocator requirement]]
+[h3 [@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html
+     Removing unused allocator functions]]
 
-Need to look into this one.
+This proposal suggests removing the `construct`, `destroy` and `address`
+member functions - all of which Boost.Unordered calls. It's near trivial
+to replace the calls with the appropriate code - and will simplify the
+implementation.
 
 [h3 [@http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#431
     431. Swapping containers with unequal allocators]]
 
-I'm following Howard Hinnant's advice and implement option 3.
+I followed Howard Hinnant's advice and implemented option 3.
 
 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
 be to double buffer the allocators. But I'm assuming that it won't throw for now.
 
+Update: the comittee have now decided that swap should do a fast swap if the
+allocator is Swappable and a slow swap using copy construction otherwise. In
+the future I develop support for concepts and do this, but what should I do for
+the current implementation and, in the future, compilers without concepts? I
+should probably change it to a slow swap.
+
 [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?]]