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).
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.
This appears to be an unavoidable problem with GCC's tuple
implementation. For example:
http://stackoverflow.com/q/23374953/2434
Appears to be okay in later versions of GCC though.
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.
I'm getting a couple of "terminate called after throwing an instance of
'test::lightweight::test_exception'" errors on the sun platform. Not
sure where they're happening, so I've made the code a tad more resilient
against exceptions that should not really be thrown.
Visual C++ is warning that memory can't be tracked for allocators whose
pointer types aren't actually pointers, which is a correct warning but
not relevant for our concerns, and is caused by the unit tests, not the
container implementation.
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>>).
