This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [v3] Fix management of non empty hash functor
- From: Paolo Carlini <paolo dot carlini at oracle dot com>
- To: François Dumont <frs dot dumont at gmail dot com>
- Cc: "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>, Jonathan Wakely <jwakely dot gcc at gmail dot com>
- Date: Fri, 04 Jan 2013 12:17:00 +0100
- Subject: Re: [v3] Fix management of non empty hash functor
- References: <50CA498A.2070902@gmail.com>
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.