apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: cvs commit: apr/tables apr_tables.c
Date Sat, 20 Jan 2001 23:48:57 GMT
On Sat, Jan 20, 2001 at 03:39:26PM -0800, rbb@covalent.net wrote:
> On Sat, 20 Jan 2001, Greg Stein wrote:
> > It wasn't clear from my checkin message :-) ... I just removed the "btable"
> > option. Binary tables are not useful, given our hash table implementation.
> > 
> > What features of a table are you looking for, which hash tables do not
> > provide?
>...
> As far as options for the btable that aren't in the hash, how about size
> of the table.  A hash table starts at 15 entries, and doubles each time it
> is expanded.  A table is created with a size specified by the person
> writing the code, and it grows by one each time.

Tables double in size since they are built on top of arrays. See
apr_push_array().

Regarding the initial size hint: we can do that.

> Another feature that remains useful, is to be able to iterate over the
> array, and know that you are getting data out in the same order that it
> was originally added.  That feature does not exist with hash tables.

Tables' API/semantics don't provide for that. Tables were intended to be a
hash, but the implementation never got there.


Regardless: nobody uses binary tables, and I don't know that anybody plans
to anywhere in the code. Hash tables are a much better than binary tables.
Tables (normal or binary) are linear-time for lookup, even though they
export a key-based style like a hash table.

Why do we need binary tables?

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message