<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 3, 2014 at 1:46 PM, Stephan Tolksdorf <span dir="ltr"><<a href="mailto:st@quanttec.com" target="_blank">st@quanttec.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":crz" style="overflow:hidden">I've attached a patch that makes the hashing implementation consistently use a 64-bit seed everywhere.  With this change the implementation should produce the same hash codes modulo SIZE_MAX + 1 for identical values independent of the platform. (Though hash_combine may still produce different results if the size of an argument type differs between platforms). I suspect the negative performance impact on 32-bit platforms should be small, but I didn't do any benchmarking. With atomics one could probably replace the thread safe local static in get_execution_seed with something that has a little less overhead.<br>

<br>
The patch also removes a FIXME from the set_fixed_execution_seed implementation and rewords the documentation string a bit, since using this function in a multi-threaded program requires some kind of external synchronization anyway.<br>
</div></blockquote></div><br>Very cool. A minor comment:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">   /// \brief Form a hash code directly from a numerical value.</div><div class="gmail_extra">
-  hash_code(size_t value) : value(value) {}</div><div class="gmail_extra">+  ///</div><div class="gmail_extra">+  /// The argument is casted to and stored as a size_t value.</div><div class="gmail_extra">+  hash_code(uint64_t value) : value(static_cast<size_t>(value)) {}</div>
<div><br></div><div>I think it would be better to store the 64-bit value internally and reduce to size_t when asked. That way we could (perhaps in the future) expose a higher fidelity uint64_t extraction mechanism.</div><div>
<br></div><div>My idea is basically that the hashing code should be 64-bit input always, and 64-bit output always, but provide easy methods for consumers which *need* to only get size_t output to truncate safely and consistently.</div>
<div><br></div><div>Does that make sense?</div></div></div>