Suppose I do not need a hasher to transform my keys, and all I need to do is map u64
's to T
's. I was thinking about a no-hasher for the default HashMap
implementation, but that seems a bit wanky (defeats the purpose). What would be a good choice in such a scenario?
Are you choosing the u64
key yourself? Then a HashMap<u64, T>
should be fine.
If you don't care about the exact key value, do you want the container to manage uniqueness of those T
s? If so, an IndexSet
lets you access items by their usize
index without further hashing. If not, then just a Vec
should do.
Does an IndexSet
allocate up to the max usize inserted? Because these u64's are network identification values, and as such, are typically very large. Gigabytes of allocation for a singular large entry would be bad.
Not necessarily, but they are being generated by a function of my choosing (randomly generated, ensured to have no collisions beforehand).
IndexSet
doesn't let you choose the usize
-- it's essentially the index of insertion order. You could also use IndexMap<u64, T>
-- then you could use either the usize
index for direct access or the u64
key for hashed access.
But it sounds like you really just need to use your u64
key in a normal map, whether that's HashMap
, BTreeMap
, IndexMap
, etc. If the bits of your keys are sufficiently random/distributed, then it seems just fine to use a no-op hasher with this. Why do you hesitate on that?
Actually, off the top of my head I thought this may have existed, but didn't know that was the name for it. Is this included within the std HashMap
?
std
only has RandomState
that builds DefaultHasher
.
Someone else asked how to do this a few days ago:
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.