On 8/24/20 5:11 PM, ikod wrote:
Thanks, but no )
This hashmap can't replace standard AA for next reason:
with standard AA you can safely do:
string[int] aa;
aa[0] = "null";
auto v = 0 in aa;
aa.remove(0);
assert(*v == "null");
aa[0] = "one";
assert(*v == "null");
Hm, I see what you mean but I am not sure I love the behavior (or would
call it safe habit to be in) to keep a pointer to something that was
subsequently deleted (obviously I understand that in case of Dlang AA it
is not really a pointer to what was deleted, it is a pointer to existing
object and only the rference was deleted from the AA). If one is using
pointers one should be mindful of deletes, etc. anyway =)
This is because AA allocate memory in GC area for every value it
store(and return pointer to it when "in" used), so even if you delete
key from AA it is still safe to use pointer to value. But this require
GC allocations.
Correct me if I'm wrong - your and mine HashMaps avoid allocations and
store values inline, so you can't use pointer to values in safe code
(value can be deleted, or replaced on next table insertion/deletion). In
order to be safe my hashmap do not support "in" operator and always
return value.
Correct, mine operates similarly (malloc plus GC.addRange), no
opBinaryRight!in
Also you may find useful safe map modification during iteration over map
items (at the cost of creating temporary table copy).
In search of absolute speed I am willing to forego this, but certainly
it could be useful in concurrency type situation
