[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Pika-dev] Re: Hashtrees a bit unflexible
From: |
Andreas Rottmann |
Subject: |
[Pika-dev] Re: Hashtrees a bit unflexible |
Date: |
Mon, 15 Mar 2004 22:54:49 +0100 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) |
Tom Lord <address@hidden> writes:
> > From: Andreas Rottmann <address@hidden>
>
> > I just noted that hackerlabs hashtrees are a bit unflexible compared
> > to the GLib ones: You cannot pass an additional pointer to e.g. the
> > hashtree_free_data_fn. I would however need this functionality to be
> > able to keep the storage in a memchunk for efficient (esp. space-wise)
> > allocation.
>
> > A hack to do so would involve using a special "rules" structure that
> > has an additional field. Is this the way it's ment to work, or should
> > hashtree functions be extended to take an additional void * argument?
> > If the argument would be last, this change wouldn't break ABI wrt
> > existing usage, I think. Tom?
>
> Data and keys should be coextensive with `struct hashtree' nodes.
> Thus, the `free_hashtree_fn' should be able to do what you want. Is
> there some reason why it can't?
>
The thing is, the data lives in a "memchunk". To free it, I need not
only the pointer to the data (item->binding, no problem so far), but
also a pointer to the memory chunk, so I need to funnel that somehow
into hashtree_free_data_fn. As noted in my other mail, this can be
worked around using the newly created hashtree_fold() function, but
this is somewhat suboptimal from a perfomance POV.
Andy
--
Andreas Rottmann | address@hidden | address@hidden | address@hidden
http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62
Beware of bugs in the above code; I have only proved it correct,
not tried it. -- Donald E. Knuth