On 21 February 2012 12:32, Szymon Gatner <szymon.gatner@gmail.com> 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.

On Tue, Feb 21, 2012 at 7:32 AM, Szymon Gatner <szymon.gatner@gmail.com> 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.

There's another potential "gotcha" lurking here: where are you getting the class-name string? Is that manually coded, or are you deriving it from typeid(myclass).name()? The latter construct is explicitly (and empirically) NOT portable.