On 13 January 2016 at 22:18, Andrey Semashev wrote:

Do you think we could add a few well-known hash functions to Boost.Hash so that they could be used for consistent results?

I think that would be best handled in a new library. I don't really want to enhance the existing one beyond its current scope, especially as the current standard proposal is a bit different to it, and supports alternative hash functions. Adding extra functions would probably also mean that it wouldn't be a header only library, which would be a problem. If you haven't seen the new proposal, it's at: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0029r0.html There's an implementation at: https://github.com/google/hashing-demo/tree/N0029R0 I assume that something based on that proposal is likely to be accepted. You could just use it (maybe I should add a macro to change the default hash function in unordered....), or perhaps a boost implementation could be based on it. One advantage of a new library is that it can have much stricter compiler requirements which should simplify the implementation.

On 13 January 2016 at 22:30, Bjorn Reese wrote:

On 01/13/2016 11:18 PM, Andrey Semashev wrote:

...

Do you think we could add a few well-known hash functions to Boost.Hash so that they could be used for consistent results?

I was just about to suggest the same...

I frequently use hash functions to calculate fingerprints that are exchanged in network protocols, and here consistent results, both across platforms and boost releases, are essential.

I think I've always been clear that the library is not appropriate for such uses. In terms of hash quality, it does nothing more than meet the existing std::hash requirements (which are very low). It's also pretty much impossible to fit a stronger hash function into the existing interface. I actually regret calling it 'hash', I probably should have called it something less general. Technically its name is 'Functional/Hash', because std::hash is in the functional header, but that didn't make much sense to anyone.

On 01/14/2016 06:18 PM, Phil Endecott wrote:

I use Boost.CRC for that sort of thing:

http://www.boost.org/doc/libs/1_60_0/libs/crc/index.html

The protocols I am using do not use fingerprinting for error correction but rather for identifying data chunks. See for instance: http://people.eng.unimelb.edu.au/jzobel/fulltext/jasist03thz.pdf You will notice that equation (1) on page 207 looks an awful lot like the default boost::hash implementation. Just to be sure, I do use my own implementation instead of boost::hash (and hash_combine) because Daniel does not guarantee its consistency. That is fine with me, but I really would like to see some named hash functions in boost that do not change, as Andrey suggested. This sounds like a suitable a GSoC project...

On 01/14/2016 08:22 PM, Peter Dimov wrote:

which (at page 67) says that the proposed hash_combine is taken from that very paper. :-)

Oh, that explains a lot :)

On 01/15/2016 12:23 AM, Phil Endecott wrote:

Bjorn Reese wrote:

...

The protocols I am using do not use fingerprinting for error correction

CRCs are not for error correction. You might be thinking of ECC?

Sorry, I meant to write error detection.

...

but rather for identifying data chunks.

A CRC is a good general-purpose hash function.

Indeed, and a good example of a named hash function already in Boost. Thanks for pointing that out. That said, no single hash function excels at every possibly use case. While you can probably use any hash function (unless we require specific features such as locality-preservation) for any use case, the quality of the results differ. Some hash functions like CRC are well-suited for error detection, and other hash functions like the one in the previously cited paper are better at identifying documents.

On 14 January 2016 at 04:54, Peter Dimov wrote:

Daniel James wrote:

...

The reason why I originally wrote that note was because it can generate different hash values when compiled for different

platforms or architectures, e.g. a 32-bit executable might generate a different hash value to a 64-bit executable.

Is this just because of pointers and floats, or are there other reasons? size_t hashing to different values perhaps?

Anything with a bigger range than size_t will have to, e.g. int64_t will hash differently on 32 and 64 bit machines. Also, user hash functions could be anything.