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 hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net