I've forgotten why I'm not using a stable release, but really should try
to avoid using snapshots for this reason. Or at least port the code for
downloading snapshots for the website.
Warning is:
allocate.hpp:335:19: warning: conversion to ???unsigned int??? from
???long unsigned int??? may alter its value [-Wconversion]
I'm not sure, but I think it's because the sizeof is a long unsigned
int, and the template parameter is an unsigned int. The sizeof isn't
even used, it's just there to get a value for expression SFINAE.
Calling sink was causing older versions of gcc to copy the container,
resulting in a compile error. So instead just disambiguate by putting
brackets around the expression.
I'm getting a couple of "terminate called after throwing an instance of
'test::lightweight::test_exception'" errors on the sun platform. Not
sure where they're happening, so I've made the code a tad more resilient
against exceptions that should not really be thrown.
Visual C++ is warning that memory can't be tracked for allocators whose
pointer types aren't actually pointers, which is a correct warning but
not relevant for our concerns, and is caused by the unit tests, not the
container implementation.
FWIW the standard says that equality is undefined behaviour if the Hash
and Pred function objects behave differently. But I think we should
support different hash functions, e.g. so that randomized hash functions
will work.
Which is to some extent going in circles, as this is how the containers
were originally implemented. But I think this is cleaner. It also fixes
a minor problem where the internal and external iterator types are
different for some containers, as the external iterators are all const.
Currently just storing the value without a const. Can do better with
C++11 constructors, so maybe should do that, and cast away const on
compilers without support.
Another problem is that std::allocator<const int> doesn't compile for
libstdc++ (and potentially other standard libraries), so
boost::unordered_set<const int> can't compile. I'm not sure if I should
work around that, as it means changing the type of the container
(i.e. to boost::unordered_set<const int,... , std::allocator<int>>).
std::allocator::construct uses a C-style cast to void pointer, so it can
accept const pointers, but allocator_traits::construct uses a static_cast
by default, so const pointers don't work. This means the implementation
needs to cast away const when constructing members of a std::pair. This
wouldn't happen if piecewise construction was used, as the members could
be constructed normally.
The rebind mechanism doesn't work for templates with multiple template
parameters on old versions of GCC. But allocators written for that
compiler will have an explicit rebind, so that should be acceptable.
This time for a more limited range of values so that equal values turn
up more often. This is a bit shoddy, but seems like the best way to
improve the existing tests without too much effort.
This was causing the hash function to be different to the equality
function. For some reason this resulted in a lot of windows test
failures, but none on linux or os x. I'm a bit confused and worried
about that.
So currently on one intel tester find_tests is failing the 'pos !=
x.end()' test, but not the 'const_pos != x_const.end()' test for
unordered_set (and possibly others, the test results are truncated). I'm
a bit stumped as to why this should be, as for unordered_set the const
and non-const versions are basically the exact same code. See if
changing the order makes any difference to what fails.
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.
