<div class="gmail_quote">On Sun, Feb 5, 2012 at 4:43 PM, Jakob Stoklund Olesen <span dir="ltr"><<a href="mailto:stoklund@2pi.dk">stoklund@2pi.dk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On Feb 5, 2012, at 4:31 PM, Talin wrote:<br>
<br>
> Patch to refactor the hashing functions for the constant unique map, to avoid code duplication.<br>
<br>
</div>Wouldn't it give nicer code if you kept the intermediate state as a class member?<br>
<br>
Something like:<br>
<br>
IncrementalHash Hash<br>
Hash.add(foo);<br>
Hahs.add(bar);<br>
return Hash.finish();</blockquote><div><br></div><div>If you're interested in building nice, generalized hashing infrastructure in Support, I think we can and should have a much better interface than this or the one Talin is proposing.</div>
<div><br></div><div>I would look at the proposed standard interfaces for hashing that Jeffrey and I are proposing for the next C++ standard. We could almost certainly implement something very similar to it, although there are a few subtleties we would need to work out surrounding name lookup.</div>
<div><br></div><div>Also, I don't really want such a weak hash function in Support. The standard libraries actually have much higher quality hash functions now.</div><div><br></div><div>Finally, we already have some hashing  routines in the DenseSet implementation. I feel this refactoring is only the tip of the ice berg, and isn't really factored properly for use in the rest of the cases.</div>
<div><br></div><div>However, as Nick hinted, I think the best solution might be to change the code Talin originally touched to use FoldingSetNodeID, which was carefully designed for such situations it seems.... A generalized hash function often isn't designed in that way.</div>
</div>