Adjusts to use less arguments on Visual C++ 11, which will hopefully fix
it on that compiler. Also changed to be a little less preprocessor
heavy. I'm not sure about the __SUNPRO_CC support, hopefully recent
versions of that compiler will have better support, and can use the
normal implementation. Will check that later.
Was getting a weird test failure for Visual C++ 11,
BOOST_NO_CXX11_HDR_TUPLE is defined, so the code doesn't support
std::tuple, but BOOST_UNORDERED_HAVE_PIECEWISE_CONSTRUCT was also
true, and so there are functions for constructing using
std::piecewise_construct/std::tuple, which don't work.
So, I'm assuming that if BOOST_UNORDERED_HAVE_PIECEWISE_CONSTRUCT is true,
then there must be a std::tuple. I guess it doesn't have full C++11 support,
which is why BOOST_NO_CXX11_HDR_TUPLE is defined, but it appears to be
good enough for us. If not, this will break things.
Busywork I guess, but I think it's more readable this way. The emplace
macros are still unreadable, but I think they're rarely used.
Btw. a bit weird that clang format has removed the indentation on the
'// emplace' comment, not sure why that is.
It was needed because std::allocator_traits::construct doesn't work with
a const pointer (e.g. pointer to the first member of a std::pair). But
now we're only calling construct if BOOST_UNORDERED_CXX11_CONSTRUCTION
is true, so the allocator_traits::construct is no longer used here.
Require good construct support and piecewise construction. I don't know
if there are any platforms with good construct support, but no piecewise
construction, if there are then they'll no longer use
'allocator_traits::construct'/'allocator_traits::destruct'.
I was having some problems in an abandoned prototype with incomplete
types, I'm not sure I will have this problem now, but I'm keeping this
anyway, as it seems useful.
The current organisation of the headers has been making less and less
sense over the years, so to simplify things, I'm just going to combine
them into a single header. This change will make it easier to do that.
Warning is:
allocate.hpp:335:19: warning: conversion to ???unsigned int??? from
???long unsigned int??? may alter its value [-Wconversion]
I'm not sure, but I think it's because the sizeof is a long unsigned
int, and the template parameter is an unsigned int. The sizeof isn't
even used, it's just there to get a value for expression SFINAE.
FWIW the standard says that equality is undefined behaviour if the Hash
and Pred function objects behave differently. But I think we should
support different hash functions, e.g. so that randomized hash functions
will work.
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>>).
std::allocator::construct uses a C-style cast to void pointer, so it can
accept const pointers, but allocator_traits::construct uses a static_cast
by default, so const pointers don't work. This means the implementation
needs to cast away const when constructing members of a std::pair. This
wouldn't happen if piecewise construction was used, as the members could
be constructed normally.
The hash and key equality functions were assigned before allocating new
buckets. If that allocation failed, then the existing elements would be
left in place - so if accessed after the exception they could be in the
wrong buckets or equivalent elements could be incorrectly grouped
together.
AFAICT it's not needed since the construct arguments and the members are
the same reference type. Maybe it was for older compilers? And it appears
to be causing issues with string literals in older versions of Visual
C++.
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'm hoping that these templated initializer lists will be considered a better
overload than the others. I have no idea if it will actually work, this is a
real shot in the dark.
The enable_if checks should probably be for implicit conversion, there might
be a chance this could override a valid call when there's an explicit
conversion.
[SVN r86419]
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]
