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.
C++17 requires that unordered_map has the same type of node as
unordered_multimap, and that unordered_set has the same type of node as
unordered_multiset. This didn't seem particularly useful to me and
contradicts the old implementation which had different nodes, I put a
lot of effort into trying to abstract out the difference and make it
selectable using a macro, so that the old implementation would still by
available for anyone who doesn't care about strict compatibility.
But I think that was a mistake, it was making things too complicated and
for too little gain. The default would still be inefficient containers
for equivalent keys, and using the macro could lead to problems down the
line.
So I've switched to using a much simpler implementation which just marks
the first node in a group of equivalent nodes. This isn't as fast when
there are a lot of elements with equivalent keys - it can't skip to the
end of a group of nodes, but at least it avoids having to do a lot of
potentially expensive comparisons.
It's also a lot closer to the intent of the standard, even if I disagree
with that intent.
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.
Daniel James