[fpc-devel] 2 Ideas for generic TDictionary and other hash containers

[Martin Frb]

On 27/03/2025 12:45, Martin Frb via fpc-devel wrote:
> On 27/03/2025 12:33, Marco van de Voort via fpc-devel wrote:
>>
>> Op 27-3-2025 om 12:28 schreef Martin Frb via fpc-devel:
>>>
>>> which returns True, if Akey was found and therefore APtr points to 
>>> existing Data, while otherwise APtr points to the empty slot, where 
>>> the data can be copied to.
>>>
>> Without a key, you can't find the bucket or whatever where to 
>> allocate, so this is not possible for all dictionaries IMHO. IOW, it 
>> violates the contract with implementation details.
>
> But in this feature, you always have the key.
>
> You just don't have the data yet. You only create the data, if it does 
> not yet exist.
>
> Its pretty much a
>   TryAdd.
>
> But instead of having data, it adds "Default(TData)", and returns a 
> pointer to the mem.
> Or, if the key existed, it returns a pointer to the existing data.
>
> Of course the pointer is only valid, until the next operation on the 
> dict (or hash container).
>
> It's just to save calculating the hash of the key twice.


It doesn't have to be a pointer.

It can be some opaque value, that can be used as "index like" lookup.
E.g. in most cases, the actual bucket index (only valid till next 
rehash, but that is the same for a pointer).

Then there can be a
   SetData(TheOpaqueIndex, Data)

This would mean it can deal with refcount for ansi string, if any 
dealing is required.


Or if preferred, it does not return at all, but internally stores the 
bucket location.
Then it Could be
   if not Dict.TryGetValue(Akey, AReturnedValue) then
     Dict.AddValueForLastTriedKey(ANewVal);

Then it can even invalidate the location, if it rehashes. But it 
increases adds a new field, as the last keys bucket location needs to be 
stored....