Boost logo

Boost Users :

Subject: Re: [Boost-users] Boost 1.68.0 - boost hashing changed ?
From: james (dirtydroog_at_[hidden])
Date: 2018-10-24 16:31:42

On Wed, Oct 24, 2018 at 12:14 PM Richard Hodges via Boost-users <
boost-users_at_[hidden]> wrote:

> On Tue, 23 Oct 2018 at 12:36, degski via Boost-users <
> boost-users_at_[hidden]> wrote:
>> On Tue, 23 Oct 2018 at 11:25, Miguel Ojeda <
>> miguel.ojeda.sandonis_at_[hidden]> 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.

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at