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 std::swap for various types. If all specializations of std::hash 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 std::shared_ptr, but other than that, what's present on this page and in the commented-out section is the complete list of standard specializations of std::hash. There isn't really a lot of substance to each specialization (what could the examples be, std::unordered_set of std::thread::id's, std::unordered_set of std::error_code'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 hash<string> is done now?

On the other hand, there are *special* specializations, such as std::vector<bool> and std::ctype<char> and std::uses_alocator<tuple>, 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<char>, 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 std::vector<bool>, since its interface is different from the std::vector. 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=60970gubbins (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)