My proposal should be consider out of any context. We don't know
what std::hash is used for in user code, this is why I am proposing this
patch even if for the moment it doesn't make any difference considering
only our usage of it.
Your remark would make more sens if we were talking about changing
std::unordered_xxx containers number of buckets policy to a power of 2
François
On 09/05/2015 00:10, Christopher Jefferson wrote:
My concern with accepting this patch is that many of libstdc++'s hash
functions are awful from a mixing point of view -- you would get
exactly the same problem from users who have integers which are always
a multiple of a power of 2 (which is in practice not uncommon). This
would give exactly the same problem.
Rather than try to "fix" one hash function like this, we should just
accept our hash functions might have low quality lower order bits.
On 8 May 2015 at 21:18, François Dumont<frs.dum...@gmail.com> wrote:
On 08/05/2015 10:02, Richard Biener wrote:
On Wed, May 6, 2015 at 10:10 PM, François Dumont<frs.dum...@gmail.com>
wrote:
Hi
Following Marc Glisse comment #4
on:https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65641 I would like to
propose this enhancement to the hash functor for pointers. It simply gets
rid of the irrelevant bits on pointers hash code based on memory
alignment
of the pointed type. The only drawback I can think of is that the type
needs
to be complete at std::hash instantiation time but is it really an issue
?
IMO it is quite obvious that the resulting hash code will be better
but
If you use a real hashing function that's not true. That is, something
else than GCCs pointer_hash (void *p) { return (uintptr_t)p >>3; }.
Sorry, I don't understand your remark. Do you mean that if someone is not
using std::hash to hash its pointers he won't benefit from the enhancement ?
It is a good point however to see that gcc is using something similar
internally.
François
