[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