Expanding a lot of the call to the implementation methods. While working
on some recent changes, I felt the call chains in error messages were
too long, this reduces that a little. It also should make debugging a
tad easier and I think it makes the methods a little more informative,
as you can see what they're doing without hunting around the
implementation file. Also reduces the number of symbols when compiling,
although I'm not sure if that will make much of a difference.
Does make the code a little long, and duplicated, but I don't think it's
particularly harmful.
So that the implementation can be moved into a single class. Still some
other methods to rename. Some methods didn't need to be renamed (e.g.
try_emplace is only used with unique keys), but still renamed for
consistency.
The standard specifies that all of these "shall not exit via an
exception". The containers have been exception safe when these throw,
but the 'noexcept' attribute on 'get_allocator' will terminate if an
exception is thrown in the copy constructor.
The standard doesn't specify a default constructor, so that is allowed
to throw an exception (not just pedantry, this makes sense if an
allocator has shared data that's allocated in the initial constructor).
Expanding a lot of the call to the implementation methods. While working
on some recent changes, I felt the call chains in error messages were
too long, this reduces that a little. It also should make debugging a
tad easier and I think it makes the methods a little more informative,
as you can see what they're doing without hunting around the
implementation file. Also reduces the number of symbols when compiling,
although I'm not sure if that will make much of a difference.
Does make the code a little long, and duplicated, but I don't think it's
particularly harmful.
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.
Rearrange the definitions to be a closer match to the standard, this
should make it easier to check how standards compliant it is. Also, some
minor code clean-ups that I noticed while doing this.
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.
