Re: hash policy patch

[François Dumont <frs dot dumont at gmail dot com>]

On 09/01/2011 08:36 PM, Paolo Carlini wrote:
> Hi,
> Today, I had time to look a bit more into these issues. I think we
> should handle one change at a time. About the first one above, I don't
> like the new __strict parameter, looks like we are going through this
> complication only because we are refactoring to use _M_next_bkt, because
> otherwise, if I understand correctly, we are not really incorrect, since
> we are talking about something like *strict* equality of *floating*
> point quantities, by itself something badly defined (indeed, carefully,
> the standard talks about "keeping the load factor below this number",
> using plain English, not a formula).

Hi

    What do you mean by the fact that there is no formula ? Is it that 
checking at any moments that for a given unordered container uc:

assert( uc.load_factor() < uc.max_load_factor() )

    I ask because I kept on studying this issue and found that we also 
have an other issue. When we compute the policy _M_next_resize we use:

    _M_next_resize = static_cast<std::size_t>(__builtin_floor(__p * 
_M_max_load_factor));

    But doing so we transform an unsigned long __p into a float value 
losing information if __p is larger than float mantissa. The resulting 
_M_next_resize might be in fact too large and the policy will request a 
rehash after the load_factor has started to be greater than 
max_load_factor. Raising the operation in double delay this effect to a 
very large number of buckets but is it enough to consider that it is not 
an issue anymore ?

Thanks