Hello Przemek,
What are opinions about NIL beeing a hash key (not from the point
of view
of this sample, but for hashes in general)?
It can be very easy implement but because we do not have separate bits
for NIL value then HB_IT_HASHKEY will not be longer functional what
will
force some additional code overhead in places which uses
HB_I[ST]_HASHKEY
macro.
There is one related subject I wanted to talk about long ago.
Adding pointer items to hash keys introduced one side effect:
when pointer item is collectible item then it will never be freed
untill it exists as hash key. For some code it maybe interesting
feature because the address in memory will never be freed so new
pointer item with the same address should not appear but for some
other code it can cause problems when pointer item is still "alive"
as hash key and its detractor is not executed when all other instances
are out of scope. We can easy change it by translating collectible
pointer items to normal pointer items when they are stored as hash
keys. But I still do not know what is better so I would like to hear
other developers opinion.
Current working looks natural and in line with the rest
of Harbour. If someone doesn't need the content of
a hash table (including collectible pointers), the hash
table should be destroyed. I can't see any disadvantage
with this.
The alternative solution looks a bit hackish to me,
f.e. what happens with these detached vars, and how the
destructor will ever be called for them (I guess
explicitly)?
In case this is an issue, maybe something like
hb_gcptr2ptr() (name tentative) function seems better,
so that user can make this conversion explicitly if needed.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
