Open lucaato opened 3 months ago
Hi @lucaato! We appreciate you submitting your first issue for our open-source project. 🌟
Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙
Using strings as keys would be a welcome addition.
The current hash map implementation only supports 32-bit hashes. However, on 64-bit architectures, a string (char *
, const char *
, or const char *const
) uses a 64-bit pointer.
Additionally, strings as keys would likely need dynamic allocation (unless only string literals were used as keys), and I think this would likely need to be handled outside of the hash map itself.
So I think some additional work is needed. I'll comment on the PR as well.
Is your enhancement proposal related to a problem? Please describe. I was trying to store strings as keys in a hashmap and quickly ran into the problem that only
uint64_t
can be stored in the map, and by looking at the implementation it's clear that this can't be solved, even by providing a custom hash function.Describe the solution you'd like If possible a new field of
struct sys_hashmap
could be added to allow defining an equality function. If specified this function could be used to compare the keys otherwise we could fallback to using the==
operator. Edit: this would not work out of the box for the cxx implementation of the map. Since that code does not even use thehash_func
defined by the user it shouldn't be a problem.Describe alternatives you've considered Haven't considered alternatives, I just want to know what maintainers think about it.