The hash and key equality functions were assigned before allocating new
buckets. If that allocation failed, then the existing elements would be
left in place - so if accessed after the exception they could be in the
wrong buckets or equivalent elements could be incorrectly grouped
together.
It seems my defect report was accepted at some point, and they tweaked
the requirements involving bucket counts. This also makes it possible to
have a bucket count of 0, which I think wasn't allowed in the past. I
don't think I'll change this implementation to do so, but I'd like to be
able to run these tests against standard implementations, so I'm
starting to take that into account.
I believe these changes were made after the C++14 standard, but I've
always been tracking the draft standards, so that doesn't really matter.
Oops, I merged the wrong 'develop' branch into master. Luckily, there's
not much of a difference, so I'm resolving the merge here, and will
merge into master soon.
The intel-linux failures I'm getting now are odd. This find test is
failing for iterator, but not const_iterator. So maybe it's a problem
with the iterator object. The failures I was getting before have
disappeared, so I'm not sure about that.
Now the intel-linux tester that was failing for erase_tests is passing,
but has started failing for find_tests instead. Oddly the test for
non-const find is failing, but the const find is fine - this doesn't
make much sense as they should be the same. Not sure, but it suggests
the problem might be in the way iterators are handled, rather than the
data structure?
Checking the iterators before checking that the keys are equal in order
to tell which part of the test is failing.
For some reason the unordered test results are not showing up any more.
This is odd, as when I try locally they do run. I don't know why this
is, but it's possible that it's because there isn't an actual project in
the test directory, so try adding one.
Also reactivate operator& for minimal test classes. Apparently I
disabled them because of a problem in a type trait, but I'm not seeing
that now. Maybe it will appear on other compilers.
There used to be a std::move test here, but it was changed to
boost::test for a wider range of testing, but I'd quite like to test
with std::move regardless.
I'm hoping that these templated initializer lists will be considered a better
overload than the others. I have no idea if it will actually work, this is a
real shot in the dark.
The enable_if checks should probably be for implicit conversion, there might
be a chance this could override a valid call when there's an explicit
conversion.
[SVN r86419]
