On Sat, Jan 20, 2001 at 03:39:26PM -0800, [EMAIL PROTECTED] 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/
