Re: [boost] [review] hash functions

In-Reply-To: <01b201c52987$e0bbb950$6801a8c0@pdimov> pdimov@mmltd.net (Peter Dimov) wrote (abridged):
If you _know_ how the default hash function will perform on your key set, you can make the decision of whether to use it or not, and if the hash function is standard, you do not have to re-evaluate your decision each time you change platforms.
I do appreciate the benefits of stability. What isn't clear is whether it trumps hash quality. This is a judgement call, in that it partly depends on which issue is more important to you. Ultimately if you want stability you can get it by using your own hasher. If you want the best quality the platform can deliver, then that's intrinsically non-portable; it should be provided by the vendor but in a standard way. We could both be made happy if boost provided 2 hashers as standard, one for stability and one for quality. However, I don't think we want to go that route at this stage, and anyway there can only be one default. This is /not/ a deal-breaker for me. I won't reject the proposal because it favours stability over hash quality. -- Dave Harris, Nottingham, UK

Dave Harris wrote:
In-Reply-To: <01b201c52987$e0bbb950$6801a8c0@pdimov> pdimov@mmltd.net (Peter Dimov) wrote (abridged):
If you _know_ how the default hash function will perform on your key set, you can make the decision of whether to use it or not, and if the hash function is standard, you do not have to re-evaluate your decision each time you change platforms.
I do appreciate the benefits of stability. What isn't clear is whether it trumps hash quality. This is a judgement call, in that it partly depends on which issue is more important to you.
Both issues are important to me. I want a tr1::unordered_map to deliver faster lookups than an ordinary std::map, preferably by default (quality) and I want it to continue delivering these faster lookups when I recompile with a different compiler/version/platform (stability). When either requirement is not fulfilled, an unordered_map is no longer a better alternative. Of course we can get this today by writing our own hashers, but the whole point is to make this optional in the majority of cases.
participants (2)
-
brangdon@cix.compulink.co.uk
-
Peter Dimov