The new indentation made some of the code difficult to read, especially
where macros were concerned, so move things around and add more explicit
namespace declarations.
It's undefined behaviour. Still happens for piecewise construction
emultation for std::pair, I don't think there's anyway to avoid it.
I had considered using offsetof to get a pointer to a member, but that's
also undefined behaviour when a pair member doesn't have standard
layout. Piecewise construction emulation has other problems anyway.
So, this mostly fixes PR #5.
I also stopped using addressof in self-asssignment checks as operator&
is fine.
In order to use the workaround for both `boost::tuple` and `std::tuple`
the function would need to detect which was being used, in order to
decide whether to use `boost::tuples::length` or `std::tuple_size`.
Probably not difficult, but I don't have any way to test an
implementation.
So instead Just assume that if `std::tuple` is available it will work
without any workaround. Presumably once the compiler was able to support
`std::tuple` it will also support the necessary overloads.
I've left the version check as 5.21 so that failures will still show up
in the tests, but I'm sure it can be 5.20 and probably earlier. Will
change before release.
It's timing out on some platforms because it's too slow. This reduces
the tag combinations for 9 to 3, which should reduce the execution time
by a third. Also slightly reduces the count combinations, but that won't
make much of a difference really - the slowest tests are still there
(when the right hand side is large).
There's an exception safety issue. Which is a pity as other than that it
seems fine. I'd assumed that support would be pretty good on all C++11
compilers, so I made it an 'all or nothing' feature, partly because
there are issues with pre-C++11 allocators, but this suggests partial
support might be desirable. Not sure I'll be able to (or want to) put
the time in though.
For when std::piecewise_construct is available, but std::tuple isn't. In
order to test better, just repeat the tests with the four possible
combinations.
The good news is that the old Sun workarounds aren't needed any more.
Unfortunately, there are a lot of exception test errors for
unordered_map and unordered_multimap when using libstdc++, which
probably means that std::pair isn't exception safe, which is a bit odd.
But first try using our allocator_traits implementation instead of the
standard one to see if that makes a difference. If it doesn't then I'll
probably just disable C++11 construction on this compiler, which should
fix the problem but will make allocators less useful.
The merge tests into containers with unique keys are failing on some
platforms. My guess is that because of differences between ordering of
nodes with equivalent keys that different nodes are being 'merged' in
the unordered containers and the tracker containers. So when creating
the fake merge, use the unordered container as a reference. This is a
little less pure, but should be a good enough test.
