From: Denis Kenzior <denkenz@gmail.com>
To: ell@lists.01.org
Subject: Re: [PATCH 3/9] hashmap: Call user supplied value free function in insert
Date: Tue, 10 Feb 2015 13:18:36 -0600 [thread overview]
Message-ID: <54DA598C.6030402@gmail.com> (raw)
In-Reply-To: <1423579344-10933-4-git-send-email-jukka.rissanen@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 2750 bytes --]
Hi Jukka,
On 02/10/2015 08:42 AM, Jukka Rissanen wrote:
> If user has supplied a value free function, then that will be
> called for each replaced entry.
> ---
> ell/hashmap.c | 27 ++++++++++++++++++++++++++-
> 1 file changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/ell/hashmap.c b/ell/hashmap.c
> index c51abfd..a204726 100644
> --- a/ell/hashmap.c
> +++ b/ell/hashmap.c
> @@ -393,7 +393,11 @@ LIB_EXPORT void l_hashmap_destroy(struct l_hashmap *hashmap,
> * @key: key pointer
> * @value: value pointer
> *
> - * Insert new @value entry with @key.
> + * Insert new @value entry with @key. If there is already an same key
> + * in the hash, the new value will replace the old one. If user has set
> + * the value free function by l_hashmap_set_value_free_function() then
> + * the user specified free function will be called in order to free the
> + * value.
> *
> * Returns: #true when value has been added and #false in case of failure
> **/
> @@ -419,6 +423,27 @@ LIB_EXPORT bool l_hashmap_insert(struct l_hashmap *hashmap,
> goto done;
> }
>
So the current implementation allows duplicates to be added. However,
it is implementation dependent what happens if you lookup a duplicate
key. With the current implementation, the item inserted first is
returned. I don't think enforcement of unique keys is required at the
hashmap_insert level. The user should not be always made to pay the
cost of duplicate detection (e.g. if he knows no duplicates will ever be
present).
If duplicates are an issue, the way to handle this in the client code
would be to
- Call l_hashmap_remove first
- Insert the new element
Alternatively, you could add an l_hashmap_replace() method call, e.g.:
bool l_hashmap_replace(struct l_hashmap *hashmap,
const void *key, void *value,
l_hashmap_destroy_func_t destroy);
> + /* If the key is already in the hash, we just replace the value */
> + for (entry = head;; entry = entry->next) {
> + if (entry->hash == hash &&
> + !hashmap->compare_func(key, entry->key)) {
> + if (entry->key != key_new) {
> + free_key(hashmap, entry->key);
> + entry->key = key_new;
> + }
So this part doesn't really match the comment above. You're also
freeing the key, which is an unnecessary step. If the keys are the
same, just reuse them.
> +
> + if (entry->value != value) {
> + free_value(hashmap, entry->value);
> + entry->value = value;
> + }
> +
> + return true;
> + }
> +
> + if (entry->next == head)
> + break;
> + }
> +
> entry = l_new(struct entry, 1);
> entry->key = key_new;
> entry->value = value;
>
Regards,
-Denis
next prev parent reply other threads:[~2015-02-10 19:18 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-10 14:42 [PATCH 0/9] hashmap fixes Jukka Rissanen
2015-02-10 14:42 ` [PATCH 1/9] hashmap: Add value free function Jukka Rissanen
2015-02-10 14:42 ` [PATCH 2/9] hashmap: Call user supplied value free function in destroy Jukka Rissanen
2015-02-10 19:07 ` Denis Kenzior
2015-02-10 14:42 ` [PATCH 3/9] hashmap: Call user supplied value free function in insert Jukka Rissanen
2015-02-10 19:18 ` Denis Kenzior [this message]
2015-02-11 9:27 ` Patrik Flykt
2015-02-11 11:04 ` Tomasz Bursztyka
2015-02-11 13:50 ` Denis Kenzior
2015-02-10 14:42 ` [PATCH 4/9] unit: hashmap: Add value free hash entry test Jukka Rissanen
2015-02-10 14:42 ` [PATCH 5/9] unit: hashmap: Add replace " Jukka Rissanen
2015-02-10 14:42 ` [PATCH 6/9] hashmap: Add re-entrancy support to foreach function Jukka Rissanen
2015-02-10 19:47 ` Denis Kenzior
2015-02-11 9:21 ` Patrik Flykt
2015-02-11 14:06 ` Denis Kenzior
2015-02-12 7:23 ` Jukka Rissanen
2015-02-12 18:02 ` Denis Kenzior
2015-02-12 7:25 ` Jukka Rissanen
2015-02-12 17:55 ` Denis Kenzior
2015-02-13 15:38 ` Luiz Augusto von Dentz
2015-02-13 17:04 ` Denis Kenzior
2015-02-13 17:36 ` Marcel Holtmann
2015-02-16 9:44 ` Luiz Augusto von Dentz
2015-02-16 16:18 ` Marcel Holtmann
2015-02-16 18:27 ` Luiz Augusto von Dentz
2015-02-16 19:03 ` Marcel Holtmann
2015-02-17 9:48 ` Tomasz Bursztyka
2015-02-17 16:41 ` Denis Kenzior
2015-02-18 8:23 ` Tomasz Bursztyka
2015-02-10 14:42 ` [PATCH 7/9] unit: hashmap: Re-entrancy tests added Jukka Rissanen
2015-02-10 14:42 ` [PATCH 8/9] hashmap: Add support to finding an element from hash Jukka Rissanen
2015-02-12 8:35 ` Jukka Rissanen
2015-02-13 0:19 ` Denis Kenzior
2015-02-10 14:42 ` [PATCH 9/9] unit: hashmap: Add unit test for l_hashmap_find Jukka Rissanen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54DA598C.6030402@gmail.com \
--to=denkenz@gmail.com \
--cc=ell@lists.01.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.