Subject: Re: hashtable update
From: Dom Lachowicz (dominicl@seas.upenn.edu)
Date: Thu May 24 2001 - 11:25:38 CDT
Hi Pat,
the new UT_HASH_PURGEDATA should look something like this:
#define UT_HASH_PURGEDATEA(type, hash, reaper) \
_hash_cursor _hc1 (hash); \
type _hval1 = (type) _hc1.first(); \
while (true) { \
if (_hval1) \
reaper (_hval1);\
if (!_hc1.more()) \
break; \
_hval1 = (type) _hc1.next (); \
}
USES:
UT_HASH_PURGEDATA (char *, m_hash, delete[]);
UT_HASH_PURGEDATA (char *, m_hash, free);
UT_HASH_PURGEDATA (PP_AttrProp, m_hash, delete);
...
Also, please make sure that your diffs don't show that I've removed any
of the PURGEDATA calls. I might've taken one or two out by mistake.
As for key ownership, keys are by definition unowned. However, there are
some calls like this where the value is unowned:
m_hash.set ((HashKeyType)szKey, UT_strdup (szValue));
Here, ownership isn't so clear. We have the following which might or
might not be useful: src/af/util/xp/ut_pool.h whose job is to just own
strings. God I wish for Java's reference counting and GC...
For anyone else reading this, my cvs updates and co's don't get past
abi/src/af/xap/xp/xap_Preview.cpp. Is there any reason for this? Out of
space maybe?
Dom
On 24 May 2001 04:40:01 -0400, Patrick Lam wrote:
> ok,
>
> i did some more hacking on the new hashtable and fixed a stupid bug which
> i'd added.
>
> it seems to now work pretty well. the only noticeable brokenness are a
> bunch of asserts covering the following comments:
>
> //UT_HASH_PURGEDATA(UT_UCSChar *, m_hashWords);
>
> i'm not quite clear what UT_HASH_PURGEDATA should do. so if someone tells
> me what to do there, we should be happy with the new hashtable.
>
> the only other problem is that we do need to decide on sane memory
> ownership semantics for the hashtable. who owns the keys, and who's
> responsible for freeing them?
>
> pat
>
>
>
This archive was generated by hypermail 2b25 : Sat May 26 2001 - 03:51:07 CDT