The propagate on move tests were failing because the values were being
copied not moved - so the container was check propagate on copy instead.
Because those tests are now weaker, and some new ones that will
hopefully work.
[SVN r74914]
I'm getting a warning from another library. I don't really need to check
debug libs anymore - that was for container_fwd which is now tested in
details.
[SVN r74840]
Helps allocators which can't use incomplete pointers, and avoid using
base pointers where that might not be possible. And some other
reorganization. Storing arguments to emplace in a structure when
variadic template parameters aren't available. Changed some of the odd
design for working with older compilers.
[SVN r74742]
Will need to deprecate the old variadic style pair construction, also
should look into extract_key, was written for compatibility with older
compilers that are no longer supported.
[SVN r74119]
Only for compilers with SFINAE expressions and recent versions of Visual
C++. Also fix Visual C++ 8, and use BOOST_UNORDERED_ prefix for all
macros.
[SVN r74106]
- Simplify mechanism for detecting traits of test allocators. There were
some portability issues, but rather than fix them I've just gone for a
simpler mechanism. Does mean that the relevant tests can't be run for
other allocators.
- Fix a couple of unnecessary_copy_tests, whose results were the wrong
way round.
- It appears that Visual C++ only implements RVO for implicitly defined
copy constructors in debug mode, so adjust a move_test to account for
the extra copies now that the copy constructors are explicitly
defined.
[SVN r73798]
It's pretty messy because I'm trying to avoid swapping allocators in
these cases. I'm also not sure of the exception requirements of
allocator swap and assignment.
[SVN r73756]
Seems to be better in some cases. For example, better forwarding if
rvalue references are supported but variadic template parameters aren't.
Also can use `boost::move` when inserting.
Older versions of gcc still fail this test. They perform more moves than
expected. It might be a limitation of Boost.Move, or maybe just poor
copy optimization.
[SVN r73539]
