diff options
| author | bors <bors@rust-lang.org> | 2013-04-03 14:04:07 -0700 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2013-04-03 14:04:07 -0700 |
| commit | 5b933aeba22a718d5dadeb395b5e3b2d183812bf (patch) | |
| tree | 5054ccf9d161bf212891a0789963666bd5ea5f86 /src/rt/sync/rust_thread.cpp | |
| parent | 6153aae809387bf5d8e99eda9d2a3c86e80d1b2d (diff) | |
| parent | cc148b58ff7a4eb6861701be61396d1a685f6657 (diff) | |
| download | rust-5b933aeba22a718d5dadeb395b5e3b2d183812bf.tar.gz rust-5b933aeba22a718d5dadeb395b5e3b2d183812bf.zip | |
auto merge of #5696 : thestinger/rust/hashmap, r=sanxiyn
This naming is free now that `oldmap` has finally been removed, so this is a search-and-replace to take advantage of that. It might as well be called `HashMap` instead of being named after the specific implementation, since there's only one. SipHash distributes keys so well that I don't think there will ever be much need to use anything but a simple hash table with open addressing. If there *is* a better way to do it, it will probably be better in all cases and can just be the default implementation. A cuckoo-hashing implementation combining a weaker hash with SipHash could be useful, but that won't be as general purpose - you would need to write a separate fast hash function specialized for the type to really take advantage of it (like taking a page from libstdc++/libc++ and just using the integer value as the "hash"). I think a more specific naming for a truly alternative implementation like that would be fine, with the nice naming reserved for the general purpose container.
Diffstat (limited to 'src/rt/sync/rust_thread.cpp')
0 files changed, 0 insertions, 0 deletions
