Re: [Boost-users] [hash] Reliability of hash_value() for std::string

Subject: Re: [Boost-users] [hash] Reliability of hash_value() for std::string
From: Daniel James (dnljms_at_[hidden])
Date: 2012-02-21 08:27:26

On 21 February 2012 12:32, Szymon Gatner <szymon.gatner_at_[hidden]> wrote:
>
> I am coding a simple serialization/factory lib and want to use class hash code
> based on std::string representing class name as a factory identifier.

It really isn't suitable for that purpose. it's an implementation of
std::hash, which is a hash function suitable for use in STL
containers.

> My question is: how portable / reliable is hash value produced by std::string
> hash_value() overload? Will it be the same across platforms? Across
> boost versions?

So far, it should be the same for any platform with the same
representation of 'std::size_t'. But that isn't guaranteed for the
future. So the answer is no.

> Or maybe actual algorithm is dictated by standard?

No, it was proposed that an algorithm be added to the standard, but
that was rejected. Probably correctly.

> Or should I just go
> with explicit
> algo like crc32?

Yes. I assume you've seen this:

http://www.boost.org/libs/crc/

Although you might consider a stronger hash function.

> btw. I was just very hardly bitten by the fact that hash_value() for
> const char* !=
> hash_value() for std::string, (it is just being treated as regular
> pointer). In other
> words hash_value("Class") != hash_value(std::string("Class")) which
> gave me few more
> gray hair. Is that desirable?

It has to do that because 'hash_value' corresponds to 'operator==' -
i.e. since operator== compares the pointer value, hash_value hashes
the pointer value. In the context of an STL hash container, it does
the right thing (considering that std::set<char*> will also compare by
pointer). But it's certainly a gotcha.