There's a problem with it causing an ambiguous overload. I don't think
there's anything we can do to fix that, so just don't test it.
There's another bug where a std::pair doesn't get correctly constructed
from an rvalue when using Clang 3.1 in C++11 mode. But I can't see any
way to easily fix that, and it's a pretty old compiler now.
I was having some problems in an abandoned prototype with incomplete
types, I'm not sure I will have this problem now, but I'm keeping this
anyway, as it seems useful.
The current organisation of the headers has been making less and less
sense over the years, so to simplify things, I'm just going to combine
them into a single header. This change will make it easier to do that.
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.
Daniel James