On 2016-01-14 01:07, Daniel James wrote:
I altered the subject to include interprocess, since this is relevant there.
On 9 December 2015 at 20:13, trafdev
wrote: 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.
Do you think we could add a few well-known hash functions to Boost.Hash so that they could be used for consistent results?