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.
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]
It looks the odd result in unnecessary_copy_tests on Visual C++ 11 is not a
bug, but add some extra tests just to make sure. Also some extra rehash and
reserve testing thrown in.
[SVN r80705]
Assigning a container requires that its elements can be assignable. Could split
the tests up so that other tests aren't assignable, but it doesn't seem worth
the hassle.
[SVN r80228]
Mainly because I want to get more info on the odd test failure for Visual C++
11. I expect that with move emulation these results could vary considerably,
and since I've only tested with gcc and clang so far, it's quite likely that
this test will now fail for other compilers.
[SVN r80200]
Getting a memory deallocation error from Sandia's linux c++11 clang. Add some
trace output to see if it gives a clue where it's going wrong.
[SVN r79793]
Compilers with rvalue references can avoid creating a node, as they can use the
value from the rvalue reference to check if the value is already in the
container (in this case it is) before creating the node. Could possibly do the
same for compilers without rvalue references, if it can get a value out of
Boost.Move's rvalue reference emulation.
[SVN r79503]
Some of this was there for older compilers, some is just premature
generalization. There's still too much metaprogramming, but these are things
that are relatively easy to remove.
[SVN r79356]
Daniel James
Marshall Clow