Reduce need for container_of in code using ck_hs #152
Labels
Comments
jpihlaja-bt
added a commit
to jpihlaja-bt/ck
that referenced
this issue
Feb 11, 2022
A common use case for hash sets is to store objects in a hash sets keyed on some embedded key within the object. The current interface requires the client to write hash and comparator functions that are specific to each object type being inserted into the hash. Alternatively, the client may store pointers to the keys in the hash set and use `container_of` to recover the actual object value. This is also quite cumbersome. This patch adds a function `ck_hs_init_from_options` that initializes a hash set from an extensible struct of options. The struct contains all the information currently passed to `ck_hs_init`, and also allows specifying a short 15 bit key offset when the hash set uses `CK_HS_MODE_OBJECT` mode. The patch sets the following invariants: - The public interface always specifies whether a parameter pointer is to a key or a value. - Hash and comparator functions are always called on pointers to keys. Fixes concurrencykit#152
|
This would be a nice quality of life improvement. Also, that forward compatible options struct is excellent. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Let the ck_hs constructor indicate the offset of the key field in pointees, thus making container_of optional.
The text was updated successfully, but these errors were encountered: