On Tue, 23 Oct 2018 at 08:45, Miguel Ojeda via Boost-users <boost-users@lists.boost.org> wrote:
On Mon, Oct 22, 2018 at 7:57 PM Shailja Prasad via Boost-users
<boost-users@lists.boost.org> wrote:
>
> I was trying to upgrade boost 1.53.0 to boost 1.68.0. But, it looks like hashing code generation has changed, since the following line gives two different hashcode for same string input.

Hm... why would you expect the hash to be always the same between
releases, compilers, etc.?

Well, uhm, because that seems to be quite handy. All NIST implementations do exactly this.

I cannot find it with a quick look at
Boost.Hash's docs anything regarding a guarantee of that. If it is
like std::hash, then it is only guaranteed to remain equal for the
duration of the program.

Sort of: "Hash functions are only required to produce the same result for the same input within a single execution of a program". The standard states a minimum requirement [with an intended [narrow] use case in mind, std::ordered_map's]. I'm not sure that is a great one and by the time we might [would like to] have constexpr std::ordered_map maybe not even tenable.
 
In other words, you cannot rely on saving it
nor comparing them to other hashes from other vendors, platforms,
architectures, compiler releases, etc.

In my view this is an omission, the option to have exactly that should [have been] available.

degski
--
If something cannot go on forever, it will stop" - Herbert Stein