> Are you really going to recommend growing the table by duplicating it?

Um... yes.

You want the data linearly in memory in the first place so you can have constant time access by index. If you want to grow a dynamic array, doing a realloc can easily cause the same effect as the article does manually (alloc new, copy data, free old), because the memory immediately after may be occupied by something else if you did any other malloc/calloc. Copying over the data is linear in time, thus degrading your constant time insert to linear time as soon as the table is full if you do a realloc for single items instead.

You may find the choice of growing when half full as in the article questionable, because then there will always be an unused half, but pretty much every, remotely practical dynamic array implementation in C (and probably a ton of other languages) does that (grow by capacity * 2 when full) to maintain amortized constant time when appending.

It's also how many popular, in production, hashtable implementations work.

From the uthash user guide, for example:

"Normal expansion - This hash attempts to keep fewer than 10 items in each bucket. When an item is added that would cause a bucket to exceed this number, the number of buckets in the hash is doubled and the items are redistributed into the new buckets. In an ideal world, each bucket will then contain half as many items as it did before."

So, the person questioning "why" should be instead explaining "why not".

This is the worst attitude I have this on HN. Look out people - its the internet's gatekeeper - making sure only legitimate/fully thought out things are published to the internet. By golly, we wouldn't want to waste bits and bytes on just random things being available on the internet.

Yes, I believe you are intended to duplicate the table once a certain load factor (fraction of elements filled) of your choosing is reached.

For linear probing, this is recommended to keep your probe lengths logarithmic:

https://www.sciencedirect.com/science/article/abs/pii/019667...

Removing elements for a hash table using linear probing is fairly non-trivial. Without using so-called “tombstones” to flag an element as deleted, you essentially have to shift elements up in the table.

Also, your rudeness is really quite unwarranted. If everyone took that attitude, where would the teaching examples ever come from?

>Are you really going to recommend growing the table by duplicating it?

Setting a reasonable initial size then doubling it and copying when (if!) it needs to grow is a pragmatic, reasonable approach that’s quite common!

A teaching tool is deliberately simplified so as not to overwhelm students with details they don't need to worry about yet. This is absolutely the right way to go about it.

I suppose it's a personal preference thing, but I like over simplified implementations when the purpose is educational.

I am more bugged by the accusation that the author did this because "look what I can do". I don't see any evidence of that.

The problem with your way of thinking, is who draws the line to define what's "half-assed"? Because everything can be improved. You should take ideas from this kind of articles, not fully working code.

do we really need more hostile, sneering, condescending, toxic pricks like you policing the web?

This comment bugs me.

100% agree with U.