khash associative array / hash map / hash set
James Blachly
james.blachly at gmail.com
Tue Aug 25 01:04:27 UTC 2020
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
More information about the Digitalmars-d-announce
mailing list