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.
There's a problem with it causing an ambiguous overload. I don't think
there's anything we can do to fix that, so just don't test it.
There's another bug where a std::pair doesn't get correctly constructed
from an rvalue when using Clang 3.1 in C++11 mode. But I can't see any
way to easily fix that, and it's a pretty old compiler now.
Calling sink was causing older versions of gcc to copy the container,
resulting in a compile error. So instead just disambiguate by putting
brackets around the expression.
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>>).
This time for a more limited range of values so that equal values turn
up more often. This is a bit shoddy, but seems like the best way to
improve the existing tests without too much effort.
So currently on one intel tester find_tests is failing the 'pos !=
x.end()' test, but not the 'const_pos != x_const.end()' test for
unordered_set (and possibly others, the test results are truncated). I'm
a bit stumped as to why this should be, as for unordered_set the const
and non-const versions are basically the exact same code. See if
changing the order makes any difference to what fails.
Daniel James