On Wed, Oct 24, 2018 at 12:14 PM Richard Hodges via Boost-users <boost-users@lists.boost.org> wrote:


On Tue, 23 Oct 2018 at 12:36, degski via Boost-users <boost-users@lists.boost.org> wrote:
On Tue, 23 Oct 2018 at 11:25, Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
> Well, uhm, because that seems to be quite handy. All NIST implementations do exactly this.

No, sorry, that is a completely different use case. Crypto hashes are
used, among other things, in network communications, persistent
storage, etc. They need to be "fixed" functions, and their standards
provide the exact definition. That is not the case at all with
std::hash or Boost.Hash.

For debugging purposes, a fixed function seems quite useful to me.

It's already difficult enough to teach new programmers not to serialise the result of std/boost hash.

Providing a means to ensure that it's predictable would strengthen the illusion that it's predictable across compilers and architectures. This would be a grave error.

I would argue the opposite. std::hash should work hard to ensure that for any two runs of the same program, the results of a hash will be wildly different. 

This would make it easier to spot incorrect uses of it.

What about maps in shared memory? You're suggesting that it's ok that one process built with version X of boost should have no expectation of being able to operate correctly with a process build with version X+1. Insanity.