-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix for dict update same key after delete it #119
base: master
Are you sure you want to change the base?
Conversation
Thanks for reporting this issue. The current design of |
I think we have 2 choices here:
In fact the existing codes don't rely on the changing of existing keys. Are you building something requires it? @jasonjoo2010 |
@doyoubi considering modification, would it never be used to be a full functional dict in future? e.g. delete or update(index -> delete -> set) Solution 1 maybe has a poor performance the commit currently would just reuse some slot deleted before through adding a simple condition when conflicted |
Or we just support deletion and modification but leave the |
Documenting the half functional dict sounds good. |
The only special things now is that we should DELETE first when the key already exists in the dict. So we can document THIS for special. Or we can add this logic inside dict_set if we feel better. Wouldn't modification be needed in future? |
Current dict implementation is very limited. I think we should have a refactor to make it fully functional. |
It's much simple than I thought to make it support setting the same key multiple times: while (1) {
struct bucket *bucket = &dict->buckets[pos];
+ // Empty, set bucket
if (!bucket->setted) {
set_bucket(bucket, hash, key, data);
return;
}
probe_dist = PSL(dict->capacity, bucket->hash, pos);
+
+ // Same key, update the bucket
+ if (probe_dist == dist && strcmp(key, bucket->key) == 0) {
+ set_bucket(bucket, hash, key, data);
+ return;
+ }
+
if (probe_dist < dist) {
if (bucket->deleted) {
set_bucket(bucket, hash, key, data); The code is not fully tested. |
I do have considered this kind of fix. But there maybe a memory management problem if we just update the pointer to a new one simply. Caller could FREE the pointer if necessarily when we force him to do existence checking when updating. |
I think the memory problem is up to the caller. If the value is dynamically allocated, |
yes, you are right. it does the responsibility of caller. btw, maybe the small fix from our training project cost us too much discussion. |
|
following calls will be fail:
dict_set(map, "test", "demo");
dict_delete(map, "test");
dict_set(map, "test", "new value"); //will not set it
this pr is submitted to fix it