C Hashmap feedback

[skifli]

Hiya everyone,

It's been a while since I've posted here, but I was looking for some feedback on a Hashmap I had recently implemented for my programming language in C. I haven't programmed in C for a few months (had and have a lot of school-related work), so I was mainly wondering if I there were any bugs lurking in the code, mainly to do with the resizing logic (in the
hashmap___resize function). I've tested the code myself, and it seems to have worked... but it was the first try, and I don't recall the last time my code worked on the first try in any language, let alone C. The link to the code is at the bottom, and just so you know, the panic function is just a custom little helper function I made myself that prints the string passed to it and then exits. If you have any more questions relating to the code feel free to ask me 🙂.

exeme-lang/src/utils/hashmap.c at main · exeme-project/exeme-lang (I think a link is better so there is more context? If not I can specifically post the code here.)

The usage is like so:

#include "./utils/hashmap.c"

int main(int argc, char **argv) {
    struct Hashmap *map = hashmap_new(hashmap___hashDJB2, DEFAULT_INITIAL_TABLE_COUNT, DEFAULT_LOAD_FACTOR);

    hashmap_set(map, "key", "value");
    hashmap_set(map, "key", "value2");

    printf("%s\n", hashmap_get(map, "key")); // "value2"

    hashmap_free(&map);
}

 

[henry227]

Looks like you did a solid job on the implementation, but have you double-checked the resizing logic when the load factor increases? Sometimes small errors in size recalculations can cause big issues.

Also, side note – double-check key preservation on collisions. It’s a common stumbling block!

 

[skifli]

Hi Henry,

Not entirely sure what you mean by double-checking the resize logic. Currently when (by default) 70% of the buckets are full, it doubles the size of the hashmap. Do you mean adding a check to make sure it does not resize too large? And with the last point, I checked by using a hashing function that always returned 0, and the correct values were returned for 3 different keys, but thanks for making me double check that.

Thanks.