thmap_destroy of non-empty tree

[nuclight]

In using like a hashmap, a need may be possible to destroy the tree without first deleting all entries, in situations when "foreach" or sibling access is not needed. Then, looking at code, I guess it will just leak all nodes. An obvious "solution" of linked list may incur too much memory overhead. Could destroy() just iterate all nodes internally and free them?

[rmind]

It could, but that will just destroy the internal nodes (and copied keys). If your values are some kind of objects, then you'll need to destroy them yourself anyway. I can see the use if you put numeric values into the pointer, though.

What's your use case?

[nuclight]

I am thinking about how to implement compression scheme in my protocol, utilizing "atoms" (think X11 or Lisp or JS's Symbol or other such languages), that is, when a string is stored in only one unique copy, and for compression an assigned integer used instead (think of repeated JSON keys or names in sysctl). For this, I see this like: server has global table of all strings for each client, using one central thmap(string -> char*). For each client, each new incoming string consulted in central thmap and then added to this client's thmap with NOCOPY and simple i++ for atom number (instead of void*) and to reverse thmap(int -> char*). In such scheme, keeping - for each client! - another (doubly?) linked list looks like too much overhead just for freeing operation on client's disconnect later, especially when majority of strings is short enough like "aes256-ctr" or typical name from sysctl.

A stripped-down test case would be utility processing input strings ignoring duplicates (using just first one), similar in spirit to e.g. ps | awk '{if (!seen[$5]) { print $5; seen[$5]=1}}'

About objects, you are right, but this reminds me about another feature that I would like to want with objects: a versions of thmap_get() and thmap_put() with struct iovec *iov, int iovcnt instead of single-chunk key (or may be a callback for updating hash). I'd like to use such for "table" format data (think of several-column indexes in SQL) when actual fields are disjoint (most likely for me that'd be not table with columns but just two strings, tag and value in parsed CBOR [RFC 8949], but iovec/iovcnt is generic enough).