I altered the subject to include interprocess, since this is relevant there.
On 9 December 2015 at 20:13, trafdev
As per hash_range docs (http://www.boost.org/doc/libs/1_59_0/doc/html/hash/reference.html#boost.hash...):
"This hash function is not intended for general use, and isn't guaranteed to be equal during separate runs of a program - so please don't use it for any persistent storage or communication."
As per code (http://www.boost.org/doc/libs/1_59_0/boost/functional/hash/hash.hpp) it uses hash_combine_impl which doesn't use any random, process_id etc values which might change during new process launches.
At the same time, in an example describing container usage in the shared memory (http://www.boost.org/doc/libs/1_59_0/doc/html/interprocess/allocators_contai...), boost::hash is being used:
typedef boost::unordered_map < KeyType , MappedType , boost::hash<KeyType> ,std::equal_to<KeyType> , ShmemAllocator> MyHashMap;
My question is: is it safe to use boost::hash in a shared (persistent) storage or it's safe only for a particular (non-pointer) types?
In this case, boost::hash docs should be changed to mention this exceptions, because otherwise no one could use boost::hash in a shared memory containers.
Sorry about the very slow reply. I'm afraid the answer is that it depends. 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. Also, I occasionally change the algorithm in new versions of boost (and probably will in the next version). For interprocess this currently won't be an issue if all the processes are using the same executable, or using executables built with same version of boost and the same architecture, but could be a problem if that isn't the case. So maybe the Interprocess documentation needs to explain this. But there's another problem coming up. The last proposal I saw for a standard generic hash function will support randomized hash functions (such as siphash) which will only work with interprocess if they are somehow seeded identically. I'll want to support whatever is accepted to the standard (although maybe as a separate library). I'll need to catch up with how that is progressing, as I haven't kept up to date.