Dave Harris wrote:
When I wrote it seemed there were still unresolved issues. In fact, I don't believe anyone has yet posted an acceptable hash_value for pointers. Presumably we want to shift out bits which are always 0 for alignment reasons.
I'm glad that I'm not the only person who's worried about alignment. But this is a problems for a cross-platform library. Either I'll have to introduce a load of macros to tweak it on various platforms (I'll need help there) or just accept it. It's going to be impossible to write a perfect hash function for pointers. I plan to start with the proposed reinterpret_cast version, get it working on platforms where we know it's broken (if there are any) and only then worry about tweaking it for specific platforms.
For example, the proposal has no specialisation for chars at all. I can't tell if that is an oversight, or whether it is a design aim [...]
I don't think it's either. Peter?
Peter has now said it is a design aim. That even you weren't sure illustrates my point :-)
Oh, this is definitely Peter's design. I obviously like it, since I decided to follow it.
Perhaps it would be better spelt as:
template <class It> void hash_combine(std::size_t& seed, It begin, It end);
Yes, I considered that. I wasn't sure whether overloading the name would help or hinder - hash_range and hash_combine are not substitutable for each other.
Oh yes, I didn't think that one through. It would be wrong. Daniel