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).
double_to_size can return std::numeric_limits<size_t>max(), so we cannot add 1 to the return value of double_to_size. That addition should be done while still working with a double, as can be seen being done on line 850 of this file.
This was uncovered by Coverity, and addresses Coverity issues CID13443 and CID12664
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.
This means data_ should get initialized in the default constructor for boost::unordered::detail::unique_node (and any other inheritors), as this constructor will be called there.
This uninitialized data member was reported by Coverity (CID 49445), which unfortunately does not seem to have any convenient way to publicly, globally address issues.
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]
