Which is to some extent going in circles, as this is how the containers
were originally implemented. But I think this is cleaner. It also fixes
a minor problem where the internal and external iterator types are
different for some containers, as the external iterators are all const.
Currently just storing the value without a const. Can do better with
C++11 constructors, so maybe should do that, and cast away const on
compilers without support.
Another problem is that std::allocator<const int> doesn't compile for
libstdc++ (and potentially other standard libraries), so
boost::unordered_set<const int> can't compile. I'm not sure if I should
work around that, as it means changing the type of the container
(i.e. to boost::unordered_set<const int,... , std::allocator<int>>).
Split node_constructor into two classes, one for constructing a node
without a value, and then another for holding it once the value is
constructed.
Do the work of constructing values in convenience functions in
allocate.hpp (construct_value_generic, construct_value, construct_pair).
Also reactivate operator& for minimal test classes. Apparently I
disabled them because of a problem in a type trait, but I'm not seeing
that now. Maybe it will appear on other compilers.
I'd put the iterators in their own namespace so that they wouldn't pick
up functions in detail via ADL, but I forgot that their template
parameters would cause that to happen anyway. The simplest way to fix
that for now is just to stuff the problematic functions into a
sub-namespace, so that they're no longer exposed.
[SVN r85280]
I couldn't find any sepecification in the standard, but I'd assume that since
`begin` and `end` are both `noexcept`, the iterator copy constructors must be.
To justify adding `noexcept` to these members, see 17.6.3.5 (part of the
allocator requirements) of n3485, which says about allocator's pointer types,
"No constructor, comparison operator, copy operation, move operation, or swap
operation on these types shall exit via an exception."
Not relevant in this case but allocator pointers also need to model
NullablePointer. From 17.6.3.3, "No operation which is part of the
NullablePointer requirements shall exit via an exception."
[SVN r84374]
Originally I was going to use two different versions of `hash_functions`, but
the recent discussion on binary compatibility persuaded me not to.
[SVN r84276]
- Move `allocator_traits` before `construct_impl` so the
`construct_impl` can be changed to use `allocator_traits`.
- Moved some move utilities out of `allocate.hpp` because they're
really nothing to do with allocation and construction.
[SVN r80220]
