Re: Hashtrees a bit unflexible

Tom Lord <lord-1tv/[email protected]> writes:

>     > From: Andreas Rottmann <[email protected]>
>
>     > 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         | [email protected]      | 118634484@ICQ | [email protected]
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