-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hashed Containers (or a Better Explanation why not) #9
Comments
Yes, I got quite a bit of interest on hackernews for unordered sets, so I started my implementation of |
It should be ready in a couple weeks |
But very buggy still. And chained, not open addressing. You shalt not make the same mistake as the STL Rehash, each are broken, insert needs to check the load_factor |
@rurban, considering it's the staging branch, I wouldn't consider it production worthy. As for linked list chained hash tables, the main benefit is that pointers to unordered set elements remain valid for the lifetime of the unordered set, which, in practically, is more important than speed. I wouldn't consider this a mistake in the STL. |
Example hashing of strings (with a relatively uninteresting hash function):
|
The README states that CTL will not have unordered_map and unordered_set. The rationale for this is quite succinct: "ordered containers are preferred, even at the cost of performance".
If CTL won't offer hashed containers, could it at least extend the explanation why red/black containers should be always preferred. It's not obvious why it would always be true. Especially, as:
The text was updated successfully, but these errors were encountered: