Talk:cpp/utility/hash

Misleading examples
The examples suggest to combine hashes by just doing h1 ^ (h2 << 1). This works fine, but in case a loop is done to combine several values, I've found that consecutive identical hashes delete each other effects. As example, let h1 = XX, h2 = 42 and h3 = 42. We do this:

h0 = h1

h0 = h0 ^ (h2<<1)

h0 = h0 ^ (h3<<1)

In the end, h0 will still have value XX.
 * That's because you're missing the essential point. The last line should be `h0 = h0 ^ (h3 << 2)` and the next would be `h0 ^= h4 << 3` and so on. Of course there is a chance one value can cancel another out, but that's how hashes work. I more serious problem when combining hashes like this is that bits get removed. I.e. if `size_t` is 64-bit and you're up to the 64th item, `h65 << 64`will always produce 0. I.e. shift is not really the best solution. JHBonarius (talk) 03:51, 17 May 2021 (PDT)

Why no need for separate pages for the specializations?
There are separate pages (or, mostly, placeholder dcl list entries) for the specializations of for various types. If all specializations of should be listed here, then all specializations of swap should be listed in std::swap? --Cubbi 13:17, 4 October 2011 (PDT)
 * btw, I missed, but other than that, what's present on this page and in the commented-out section is the complete list of standard specializations of . There isn't really a lot of substance to each specialization (what could the examples be, of 's,  of 's, etc?). Perhaps a sensible consistent approach for such function template specializations would be to list each standard specialization as a tdcl list item twice: once in the class page and once in the function template page? The way  is done now?
 * On the other hand, there are *special* specializations, such as and  and, whose semantics, not just implementation, are significantly different from the general template - those, I think, deserve their own pages. --Cubbi 13:54, 4 October 2011 (PDT)
 * ... although perhaps they don't deserve frontpage mention as I placed ctype, I think I'll move the link to it inside cpp/locale/ctype --Cubbi 13:56, 4 October 2011 (PDT)


 * I've noticed this talk only now. I agree with everything - this is the only possible way to consistently represent various specializations/overloads. I've proved that using the trial and error approach. LOL. P12 14:35, 4 October 2011 (PDT)
 * BTW I think we need a separate page for, since its interface is different from the . Mixing these two pages would result in a lot of confusion. Still, there's not much work to be done as we could use already existing templates.P12 14:40, 4 October 2011 (PDT)

Hash for enums
I misunderstood the section about enum specializations in C++14 so I have re-worded it slightly. It's quite surprising that libstdc++ (as of gcc 5.3) still doesn't implement hash for enums. Seems to be fixed but not released: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60970 gubbins (talk) 16:58, 18 July 2016 (PDT)

boost::hash_combine
There is this in the examples: or use boost::hash_combine (see Discussion)

But nothing in discussion, just remove "(see Discussion)"?


 * Removed --Ybab321 (talk) 04:54, 20 July 2021 (PDT)


 * The complete history:
 * happened
 * fix 1
 * fix 2
 * --Space Mission (talk) 05:14, 20 July 2021 (PDT)


 * Guess I was wrong about it being a copy+paste error. Is it worth pointing out the "Misleading examples" comment on the page somehow? --Ybab321 (talk) 06:29, 20 July 2021 (PDT)

noexcept
Is it really true that hash functions should not throw? I don't see it on the latest draft [1] nor is it on cppreference's own page on the Hash named requirement [2].

[1] [hash.requirements] http://eel.is/c++draft/hash.requirements

[2] https://en.cppreference.com/w/cpp/named_req/Hash

Gracefu (talk) 08:02, 31 August 2021 (PDT)


 * the standard only promises that all library hashes (with three exceptions, noted on this page) are noexcept. The wording is in unord.hash, it was introduced in p0599 --Cubbi (talk) 12:30, 31 August 2021 (PDT)