Also manually call the emplace macro up to 9 arguments, nicer error
messages for little effort.
Does it matter that there's no longer a nice backend for
`please_ignore_this_overload`? I don't think so, I was worried that it
would be confusing if triggered, but I'm not really aware of that ever
happening.
GCC 4.6 doesn't support using variadic arguments for a fixed length template.
There's a config macro for this, but might as well use the same code
everywhere.
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'.
Daniel James