4 ms·

POSIX hsearch tables are terrible. There's a reason why nobody uses them. One at a time per program, having to know how big the table needs to be at initializa

POSIX hsearch tables are terrible. There's a reason why nobody uses them. One at a time per program, having to know how big the table needs to be at initialization time with no automatic resizing, an API that's very limited (no way to remove entries, iterate over entries, tell how many entries are in the table, ...)

akira2501 2y ago
> One at a time per program Reentrant versions have existed for quite some time. > having to know how big the table needs to be at initialization time with no automatic resizing The posted implementation resizes by creating an entirely new table and then moving all entries. The exact same mechanism is available with hsearch. > no way to remove entries, iterate over entries Strong downside but the posted implementation has no removal function either. It also leaks key memory on resize and free. It's iterator would need modification to allow delete during iteration. > tell how many entries are in the table somewhat_reasonable_point++;
- shawn_w 2y ago
  >> One at a time per program >Reentrant versions have existed for quite some time. Not in POSIX. glibc has one, but that doesn't do much good if you want your code to work portably. I do see they've made their way into Free and Net BSD, but not Open. Are they available for Mac? Any of the surviving commercial unixes? >> having to know how big the table needs to be at initialization time with no automatic resizing >The posted implementation resizes by creating an entirely new table and then moving all entries. The exact same mechanism is available with hsearch. That's how resizing a hash table typically works, yes. Except it's normally done automatically and transparently by the hash table code. hsearch doesn't do that. And since it doesn't give you a way to iterate over values in the table, you'd have to keep a separate list of everything you add to it in order to manually delete the existing table and make a bigger one and re-add everything to it... Like I said, it's terrible.

akira2501 2y ago

> One at a time per program Reentrant versions have existed for quite some time. > having to know how big the table needs to be at initialization time with no automatic resizing The posted implementation resizes by creating an entirely new table and then moving all entries. The exact same mechanism is available with hsearch. > no way to remove entries, iterate over entries Strong downside but the posted implementation has no removal function either. It also leaks key memory on resize and free. It's iterator would need modification to allow delete during iteration. > tell how many entries are in the table somewhat_reasonable_point++;

shawn_w 2y ago
>> One at a time per program >Reentrant versions have existed for quite some time. Not in POSIX. glibc has one, but that doesn't do much good if you want your code to work portably. I do see they've made their way into Free and Net BSD, but not Open. Are they available for Mac? Any of the surviving commercial unixes? >> having to know how big the table needs to be at initialization time with no automatic resizing >The posted implementation resizes by creating an entirely new table and then moving all entries. The exact same mechanism is available with hsearch. That's how resizing a hash table typically works, yes. Except it's normally done automatically and transparently by the hash table code. hsearch doesn't do that. And since it doesn't give you a way to iterate over values in the table, you'd have to keep a separate list of everything you add to it in order to manually delete the existing table and make a bigger one and re-add everything to it... Like I said, it's terrible.