[v3] Fix management of non empty hash functor

Paolo Carlini paolo.carlini@oracle.com
Fri Jan 4 11:17:00 GMT 2013


Hi,

On 12/13/2012 10:32 PM, François Dumont wrote:
> Hi
>
>     As part of a performance patch proposed in an other mailing thread 
> was a patch to improve management of hash functor with state. This 
> part is I think less sensible than the performance patch so I propose 
> it independently. I only would like to commit the modification on the 
> performance tests here if you don't mind.
>
>     Thanks to this patch caching the hash code or not doesn't depend 
> on the hash functor to be empty of final anymore. I only keep the 
> default constructible condition so that local_iterator can be default 
> constructible, considering it is a Standard request.
I'm finally having a closer look at this work of yours (sorry aboutt the 
delay!) and I think we want something similar for 4.8.0. However, to be 
honest, I'm not convinced we are implementing the general idea in the 
best way, in particular I don't like the much more complex access 
control structure, _Hash_code_base loses encapsulation, etc. Did you 
consider maybe adding friend declarations in a few places?

Jon, do you have suggestiong? The idea of managing to get rid of the 
empty & !final requirement for dispatching seems right to me.

By the way, I'm also not convinced that is_integral is the right 
category, I think is_scalar for example is better: pointers are common 
and very similar in terms of std::hash, likewise floating point 
quantities (with the possible exception of long double, but I don't 
think we should spend time on it).

Paolo.



More information about the Libstdc++ mailing list