Therefore get rid of all of that and replace inheritance by lifting std::iterator's members into the derived class.
Signed-off-by: Daniela Engert <dani@ngrt.de>
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.
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.
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.
