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