How about adding shat() macro that emulates stl's unodred_map's T& operator[]( const Key& key )?

[srdjanstipic]

With STL:

unordered_map<string, int> strmap;
for (char *word: words) strmap[word]++;

Current stb_ds.h:

struct {char *key; int count} sm;
for (char *word: words) {
  ssize_t i = shgeti(hm, word);
  if (i < 0) {
    shput(hm, word, 1 /* count */);
  } else {
    hm[i].count++;
  }
}

Proposed shat() macro:

struct {char *key; int count} sm;
for (char *word: words) shat(m, word).count++;

Possible implementation:

#define shat(t, k)                                                             \
  ((t)[((t) = stbds_hmput_key_wrapper((t), sizeof *(t), (void *)(k),           \
                                      sizeof(t)->key, STBDS_HM_STRING),        \
        stbds_temp((t)-1))])

[nothings]

So, since I don't do C++ and the request never specifies explicitly, I believe the proposal is:

A function which returns a pointer to the hash table entry in a hash table, which creates one if there isn't one already.

The main reason is that C++ has constructors, C doesn't. You need some mechanism to initialize the hash table slot the first time you write to it. Your suggestion just assumes it's ok if they're zero initialized, but it doesn't seem worth adding this function and ambiguity to me. C code is expected to be relatively explicit about these sorts of things. And a user can always write this function themselves if they need it frequently.

[srdjanstipic]

Thanks for the quick reply :)
and sorry for posting a confusing question. :(

A function which returns a pointer to the hash table entry in a hash table, which creates one if there isn't one already.

Yes You understood me correctly. :)

Your suggestion just assumes it's ok if they're zero initialized,
but it doesn't seem worth adding this function and ambiguity to me

Yes and no.
String/hash table already have default values:

      shdefault
        TV hmdefault(T*, TV value)
        TV shdefault(T*, TV value)
          Sets the default value for the hashmap, the value which will be
          returned by hmget/shget if the key is not present.

So, the hash table could just copy the default value that is provided by user
or use zero initialisation if not provided.

My suggestion was just that the following is simpler (and potentially faster):

shat(m, word).count++;

then:

  ssize_t i = shgeti(hm, word); // first lookup
  if (i < 0) {
    shput(hm, word, 1 /* count */); // second lookup
  } else {
    hm[i].count++;
  }
}

because shat() does only one lookup
while shgeti() + shput() do two lookups
if the element is not in the table.

To conclude.
The code that usesshat():

1. could be simpler
2. could be faster when constructing new value (one lookup vs 2 lookups)
3. could use default value provided by user (or zero initialised value if not provided).
4. "fixes" the following potential problem with shgeti() from the documentation:

  * The default value for the hash table is stored in foo[-1], so if you
    use code like 'hmget(T,k)->value = 5' you can accidentally overwrite
    the value stored by hmdefault if 'k' is not present.

Any thoughts? :)

P.S.
I am not trying to push any feature request.
I just thought that shat() could be a nice added feature to already great stb_ds.h. :)

[nothings]

It is faster in that scenario, but only if you don't update most things. Currently, if you incremented an item up to 10, you'll have done 11 lookups if you're storing a pointer in the hash table, or 20 lookups if you're storing the value in the hash table. Your proposal only brings 11 down to 10.

Of course, if most things get incremented 1 or 2 times, the savings is more significant. But if you want the fastest possible hash table, you shouldn't be using stb_ds, as the hash function errs on the side of secure more than fast.

It's non-trivial to copy the value from the default slot into a newly-created slot.

Bottom line is, there's been enough bugs over the years from this sort of change that I'd rather not risk discovering a whole new class of bugs from trying to make it work.

[srdjanstipic]

I totally understand you and thanks for the replays. :)