You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by gs...@apache.org on 2001/01/20 12:34:32 UTC
cvs commit: apr/tables apr_tables.c
gstein 01/01/20 03:34:32
Modified: include apr_tables.h
tables apr_tables.c
Log:
yes, you *will* use a hash instead. any questions can be directed to Bubba.
Revision Changes Path
1.12 +0 -159 apr/include/apr_tables.h
Index: apr_tables.h
===================================================================
RCS file: /home/cvs/apr/include/apr_tables.h,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -u -r1.11 -r1.12
--- apr_tables.h 2001/01/18 20:07:22 1.11
+++ apr_tables.h 2001/01/20 11:34:32 1.12
@@ -80,7 +80,6 @@
* published.
*/
typedef struct apr_table_t apr_table_t;
-typedef struct apr_btable_t apr_btable_t;
typedef struct apr_array_header_t apr_array_header_t;
/** An opaque array type */
@@ -112,21 +111,6 @@
#endif
};
-/** The opaque binary-content table type */
-struct apr_btable_t {
- /* This has to be first to promote backwards compatibility with
- * older modules which cast a apr_table_t * to an apr_array_header_t *...
- * they should use the table_elts() function for most of the
- * cases they do this for.
- */
- /** The underlying array for the table */
- apr_array_header_t a;
-#ifdef MAKE_TABLE_PROFILE
- /** Who created the array. */
- void *creator;
-#endif
-};
-
/**
* The (opaque) structure for string-content tables.
*/
@@ -143,11 +127,6 @@
};
/**
- * The (opaque) structure for binary-content tables.
- */
-typedef struct apr_btable_entry_t apr_btable_entry_t;
-
-/**
* A transparent type for items stored in binary-content tables, and
* possibly elsewhere.
*/
@@ -162,16 +141,6 @@
void *data;
} apr_item_t;
-/** The type for each entry in a binary-content table */
-struct apr_btable_entry_t {
- /** The key for the current table entry */
- char *key; /* maybe NULL in future;
- * check when iterating thru table_elts
- */
- /** The value for the current table entry */
- apr_item_t *val;
-};
-
/**
* Get the elements from a table
* @param t The table
@@ -181,14 +150,6 @@
#define apr_table_elts(t) ((apr_array_header_t *)(t))
/**
- * Get the elements from a binary table
- * @param t The table
- * @return An array containing the contents of the table
- * @deffunc apr_array_header_t *apr_table_elts(apr_table_t *t)
- */
-#define apr_btable_elts(t) apr_table_elts(t)
-
-/**
* Determine if the table is empty
* @param t The table to check
* @return True if empty, Falso otherwise
@@ -196,13 +157,6 @@
*/
#define apr_is_empty_table(t) (((t) == NULL) \
|| (((apr_array_header_t *)(t))->nelts == 0))
-/**
- * Determine if the binary table is empty
- * @param t The table to check
- * @return True if empty, Falso otherwise
- * @deffunc int apr_is_empty_btable(apr_table_t *t)
- */
-#define apr_is_empty_btable(t) apr_is_empty_table(t)
/**
* Create an array
@@ -301,15 +255,6 @@
APR_DECLARE(apr_table_t *) apr_make_table(struct apr_pool_t *p, int nelts);
/**
- * Make a new table capable of storing binary data
- * @param p The pool to allocate the pool out of
- * @param nelts The number of elements in the initial table.
- * @return The new table.
- * @deffunc apr_table_t *apr_make_btable(apr_pool_t *p, int nelts)
- */
-APR_DECLARE(apr_btable_t *) apr_make_btable(struct apr_pool_t *p, int nelts);
-
-/**
* Create a new table and copy another table into it
* @param p The pool to allocate the new table out of
* @param t The table to copy
@@ -320,16 +265,6 @@
const apr_table_t *t);
/**
- * Create a new binary table and copy another table into it
- * @param p The pool to allocate the new table out of
- * @param t The table to copy
- * @return A copy of the table passed in
- * @deffunc apr_table_t *apr_copy_btable(apr_pool_t *p, const apr_btable_t *t)
- */
-APR_DECLARE(apr_btable_t *) apr_copy_btable(struct apr_pool_t *p,
- const apr_btable_t *t);
-
-/**
* Delete all of the elements from a table
* @param t The table to clear
* @deffunc void apr_clear_table(apr_table_t *t)
@@ -337,13 +272,6 @@
APR_DECLARE(void) apr_clear_table(apr_table_t *t);
/**
- * Delete all of the elements from a binary table
- * @param t The table to clear
- * @deffunc void apr_clear_btable(apr_btable_t *t)
- */
-APR_DECLARE(void) apr_clear_btable(apr_btable_t *t);
-
-/**
* Get the value associated with a given key from the table. After this call,
* The data is still in the table
* @param t The table to search for the key
@@ -354,17 +282,6 @@
APR_DECLARE(const char *) apr_table_get(const apr_table_t *t, const char *key);
/**
- * Get the value associated with a given key from a binary table. After this
- * call, the data is still in the table.
- * @param t The table to search for the key
- * @param key The key to search for
- * @return The value associated with the key
- * @deffunc const apr_item_t *apr_btable_get(const apr_btable_t *t, const char *key)
- */
-APR_DECLARE(const apr_item_t *) apr_btable_get(const apr_btable_t *t,
- const char *key);
-
-/**
* Add a key/value pair to a table, if another element already exists with the
* same key, this will over-write the old data.
* @param t The table to add the data to.
@@ -378,20 +295,6 @@
const char *val);
/**
- * Add a key/value pair to a binary table if another element already exists
- * with the same key, this will over-write the old data.
- * @param t The table to add the data to.
- * @param key The key fo use
- * @param size The size of the data to add
- * @param val The value to add
- * @tip When adding data, this function makes a copy of both the key and the
- * value.
- * @deffunc void apr_btable_set(apr_btable_t *t, const char *key, size_t size, const void *val)
- */
-APR_DECLARE(void) apr_btable_set(apr_btable_t *t, const char *key,
- size_t size, const void *val);
-
-/**
* Add a key/value pair to a table, if another element already exists with the
* same key, this will over-write the old data.
* @param t The table to add the data to.
@@ -404,20 +307,6 @@
*/
APR_DECLARE(void) apr_table_setn(apr_table_t *t, const char *key,
const char *val);
-/**
- * Add a key/value pair to a binary table if another element already exists
- * with the same key, this will over-write the old data.
- * @param t The table to add the data to.
- * @param key The key fo use
- * @param size The size of the data to add
- * @param val The value to add
- * @tip When adding data, this function does not make a copy of the key or the
- * value, so care should be taken to ensure that the values will not
- * change after they have been added..
- * @deffunc void apr_btable_setn(apr_btable_t *t, const char *key, size_t size, const void *val)
- */
-APR_DECLARE(void) apr_btable_setn(apr_btable_t *t, const char *key,
- size_t size, const void *val);
/**
* Remove data from the table
@@ -428,14 +317,6 @@
APR_DECLARE(void) apr_table_unset(apr_table_t *t, const char *key);
/**
- * Remove data from a binary table
- * @param t The table to remove data from
- * @param key The key of the data being removed
- * @deffunc void apr_btable_unset(apr_btable_t *t, const char *key)
- */
-APR_DECLARE(void) apr_btable_unset(apr_btable_t *t, const char *key);
-
-/**
* Add data to a table by merging the value with data that has already been
* stored
* @param t The table to search for the data
@@ -473,20 +354,6 @@
const char *val);
/**
- * Add data to a binary table, regardless of whether there is another element
- * with the same key.
- * @param t The table to add to
- * @param key The key to use
- * @param size The size of the value to add
- * @param val The value to add.
- * @tip When adding data, this function makes a copy of both the key and the
- * value.
- * @deffunc void apr_btable_add(apr_btable_t *t, const char *key, size_t size, const char *val)
- */
-APR_DECLARE(void) apr_btable_add(apr_btable_t *t, const char *key,
- size_t size, const void *val);
-
-/**
* Add data to a table, regardless of whether there is another element with the
* same key.
* @param t The table to add to
@@ -501,21 +368,6 @@
const char *val);
/**
- * Add data to a binary table, regardless of whether there is another element
- * with the same key.
- * @param t The table to add to
- * @param key The key to use
- * @param size The size of the value to add
- * @param val The value to add.
- * @tip When adding data, this function does not make a copy of the key or the
- * value, so care should be taken to ensure that the values will not
- * change after they have been added..
- * @deffunc void apr_btable_addn(apr_btable_t *t, const char *key, size_t size, const char *val)
- */
-APR_DECLARE(void) apr_btable_addn(apr_btable_t *t, const char *key,
- size_t size, const void *val);
-
-/**
* Merge two tables into one new table
* @param p The pool to use for the new table
* @param overlay The first table to put in the new table
@@ -526,17 +378,6 @@
APR_DECLARE(apr_table_t *) apr_overlay_tables(struct apr_pool_t *p,
const apr_table_t *overlay,
const apr_table_t *base);
-/**
- * Merge two binary tables into one new table
- * @param p The pool to use for the new table
- * @param overlay The first table to put in the new table
- * @param base The table to add at the end of the new table
- * @return A new table containing all of the data from the two passed in
- * @deffunc apr_btable_t *apr_overlay_tables(apr_pool_t *p, const apr_btable_t *overlay, const apr_btable_t *base);
- */
-APR_DECLARE(apr_btable_t *) apr_overlay_btables(struct apr_pool_t *p,
- const apr_btable_t *overlay,
- const apr_btable_t *base);
/**
* Iterate over a table running the provided function once for every
1.10 +0 -247 apr/tables/apr_tables.c
Index: apr_tables.c
===================================================================
RCS file: /home/cvs/apr/tables/apr_tables.c,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -u -r1.9 -r1.10
--- apr_tables.c 2000/12/22 16:54:57 1.9
+++ apr_tables.c 2001/01/20 11:34:32 1.10
@@ -304,17 +304,6 @@
return t;
}
-APR_DECLARE(apr_btable_t *) apr_make_btable(apr_pool_t *p, int nelts)
-{
- apr_btable_t *t = apr_palloc(p, sizeof(apr_btable_t));
-
- make_array_core(&t->a, p, nelts, sizeof(apr_btable_entry_t));
-#ifdef MAKE_TABLE_PROFILE
- t->creator = __builtin_return_address(0);
-#endif
- return t;
-}
-
APR_DECLARE(apr_table_t *) apr_copy_table(apr_pool_t *p, const apr_table_t *t)
{
apr_table_t *new = apr_palloc(p, sizeof(apr_table_t));
@@ -334,36 +323,11 @@
return new;
}
-APR_DECLARE(apr_btable_t *) apr_copy_btable(apr_pool_t *p,
- const apr_btable_t *t)
-{
- apr_btable_t *new = apr_palloc(p, sizeof(apr_btable_entry_t));
-
-#ifdef POOL_DEBUG
- /* we don't copy keys and values, so it's necessary that t->a.pool
- * have a life span at least as long as p
- */
- if (!apr_pool_is_ancestor(t->a.cont, p)) {
- fprintf(stderr, "copy_btable: t's pool is not an ancestor of p\n");
- abort();
- }
-#endif
- make_array_core(&new->a, p, t->a.nalloc, sizeof(apr_btable_entry_t));
- memcpy(new->a.elts, t->a.elts, t->a.nelts * sizeof(apr_btable_entry_t));
- new->a.nelts = t->a.nelts;
- return new;
-}
-
APR_DECLARE(void) apr_clear_table(apr_table_t *t)
{
t->a.nelts = 0;
}
-APR_DECLARE(void) apr_clear_btable(apr_btable_t *t)
-{
- t->a.nelts = 0;
-}
-
APR_DECLARE(const char *) apr_table_get(const apr_table_t *t, const char *key)
{
apr_table_entry_t *elts = (apr_table_entry_t *) t->a.elts;
@@ -382,25 +346,6 @@
return NULL;
}
-APR_DECLARE(const apr_item_t *) apr_btable_get(const apr_btable_t *t,
- const char *key)
-{
- apr_btable_entry_t *elts = (apr_btable_entry_t *) t->a.elts;
- int i;
-
- if (key == NULL) {
- return NULL;
- }
-
- for (i = 0; i < t->a.nelts; ++i) {
- if (!strcasecmp(elts[i].key, key)) {
- return elts[i].val;
- }
- }
-
- return NULL;
-}
-
APR_DECLARE(void) apr_table_set(apr_table_t *t, const char *key,
const char *val)
{
@@ -435,46 +380,6 @@
}
}
-APR_DECLARE(void) apr_btable_set(apr_btable_t *t, const char *key,
- size_t size, const void *val)
-{
- register int i, j, k;
- apr_btable_entry_t *elts = (apr_btable_entry_t *) t->a.elts;
- apr_item_t *item;
- int done = 0;
-
- item = apr_pcalloc(t->a.cont, sizeof(apr_item_t));
- item->size = size;
- item->data = apr_pcalloc(t->a.cont, size);
- memcpy(item->data, val, size);
-
- for (i = 0; i < t->a.nelts; ) {
- if (!strcasecmp(elts[i].key, key)) {
- if (!done) {
- elts[i].val = item;
- done = 1;
- ++i;
- }
- else { /* delete an extraneous element */
- for (j = i, k = i + 1; k < t->a.nelts; ++j, ++k) {
- elts[j].key = elts[k].key;
- elts[j].val = elts[k].val;
- }
- --t->a.nelts;
- }
- }
- else {
- ++i;
- }
- }
-
- if (!done) {
- elts = (apr_btable_entry_t *) table_push((apr_btable_t *) t);
- elts->key = apr_pstrdup(t->a.cont, key);
- elts->val = item;
- }
-}
-
APR_DECLARE(void) apr_table_setn(apr_table_t *t, const char *key,
const char *val)
{
@@ -522,58 +427,6 @@
}
}
-APR_DECLARE(void) apr_btable_setn(apr_btable_t *t, const char *key,
- size_t size, const void *val)
-{
- register int i, j, k;
- apr_btable_entry_t *elts = (apr_btable_entry_t *) t->a.elts;
- int done = 0;
- apr_item_t *item;
-
-#ifdef POOL_DEBUG
- {
- if (!apr_pool_is_ancestor(apr_find_pool(key), t->a.cont)) {
- fprintf(stderr, "table_set: key not in ancestor pool of t\n");
- abort();
- }
- if (!apr_pool_is_ancestor(apr_find_pool(val), t->a.cont)) {
- fprintf(stderr, "table_set: val not in ancestor pool of t\n");
- abort();
- }
- }
-#endif
-
- item = (apr_item_t *) apr_pcalloc(t->a.cont, size);
- item->size = size;
- item->data = (void *)val;
-
- for (i = 0; i < t->a.nelts; ) {
- if (!strcasecmp(elts[i].key, key)) {
- if (!done) {
- elts[i].val = item;
- done = 1;
- ++i;
- }
- else { /* delete an extraneous element */
- for (j = i, k = i + 1; k < t->a.nelts; ++j, ++k) {
- elts[j].key = elts[k].key;
- elts[j].val = elts[k].val;
- }
- --t->a.nelts;
- }
- }
- else {
- ++i;
- }
- }
-
- if (!done) {
- elts = (apr_btable_entry_t *) table_push((apr_table_t *)t);
- elts->key = (char *)key;
- elts->val = item;
- }
-}
-
APR_DECLARE(void) apr_table_unset(apr_table_t *t, const char *key)
{
register int i, j, k;
@@ -599,31 +452,6 @@
}
}
-APR_DECLARE(void) apr_btable_unset(apr_btable_t *t, const char *key)
-{
- register int i, j, k;
- apr_btable_entry_t *elts = (apr_btable_entry_t *) t->a.elts;
-
- for (i = 0; i < t->a.nelts; ) {
- if (!strcasecmp(elts[i].key, key)) {
-
- /* found an element to skip over
- * there are any number of ways to remove an element from
- * a contiguous block of memory. I've chosen one that
- * doesn't do a memcpy/bcopy/array_delete, *shrug*...
- */
- for (j = i, k = i + 1; k < t->a.nelts; ++j, ++k) {
- elts[j].key = elts[k].key;
- elts[j].val = elts[k].val;
- }
- --t->a.nelts;
- }
- else {
- ++i;
- }
- }
-}
-
APR_DECLARE(void) apr_table_merge(apr_table_t *t, const char *key,
const char *val)
{
@@ -683,21 +511,6 @@
elts->val = apr_pstrdup(t->a.cont, val);
}
-APR_DECLARE(void) apr_btable_add(apr_btable_t *t, const char *key,
- size_t size, const void *val)
-{
- apr_btable_entry_t *elts = (apr_btable_entry_t *) t->a.elts;
- apr_item_t *item;
-
- item = (apr_item_t *) apr_pcalloc(t->a.cont, sizeof(apr_item_t));
- item->size = size;
- item->data = apr_pcalloc(t->a.cont, size);
- memcpy(item->data, val, size);
- elts = (apr_btable_entry_t *) table_push((apr_btable_t *)t);
- elts->key = apr_pstrdup(t->a.cont, key);
- elts->val = item;
-}
-
APR_DECLARE(void) apr_table_addn(apr_table_t *t, const char *key,
const char *val)
{
@@ -721,34 +534,6 @@
elts->val = (char *)val;
}
-APR_DECLARE(void) apr_btable_addn(apr_btable_t *t, const char *key,
- size_t size, const void *val)
-{
- apr_btable_entry_t *elts = (apr_btable_entry_t *) t->a.elts;
- apr_item_t *item;
-
-#ifdef POOL_DEBUG
- {
- if (!apr_pool_is_ancestor(apr_find_pool(key), t->a.cont)) {
- fprintf(stderr, "table_set: key not in ancestor pool of t\n");
- abort();
- }
- if (!apr_pool_is_ancestor(apr_find_pool(val), t->a.cont)) {
- fprintf(stderr, "table_set: key not in ancestor pool of t\n");
- abort();
- }
- }
-#endif
-
- item = (apr_item_t *) apr_pcalloc(t->a.cont, sizeof(apr_item_t));
- item->size = size;
- item->data = apr_pcalloc(t->a.cont, size);
- memcpy(item->data, val, size);
- elts = (apr_btable_entry_t *) table_push((apr_btable_t *)t);
- elts->key = (char *)key;
- elts->val = item;
-}
-
APR_DECLARE(apr_table_t *) apr_overlay_tables(apr_pool_t *p,
const apr_table_t *overlay,
const apr_table_t *base)
@@ -773,38 +558,6 @@
#endif
res = apr_palloc(p, sizeof(apr_table_t));
- /* behave like append_arrays */
- res->a.cont = p;
- copy_array_hdr_core(&res->a, &overlay->a);
- apr_array_cat(&res->a, &base->a);
-
- return res;
-}
-
-APR_DECLARE(apr_btable_t *) apr_overlay_btables(apr_pool_t *p,
- const apr_btable_t *overlay,
- const apr_btable_t *base)
-{
- apr_btable_t *res;
-
-#ifdef POOL_DEBUG
- /* we don't copy keys and values, so it's necessary that
- * overlay->a.pool and base->a.pool have a life span at least
- * as long as p
- */
- if (!apr_pool_is_ancestor(overlay->a.cont, p)) {
- fprintf(stderr,
- "overlay_tables: overlay's pool is not an ancestor of p\n");
- abort();
- }
- if (!apr_pool_is_ancestor(base->a.cont, p)) {
- fprintf(stderr,
- "overlay_tables: base's pool is not an ancestor of p\n");
- abort();
- }
-#endif
-
- res = apr_palloc(p, sizeof(apr_btable_t));
/* behave like append_arrays */
res->a.cont = p;
copy_array_hdr_core(&res->a, &overlay->a);
Re: cvs commit: apr/tables apr_tables.c
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
Greg did the right thing -- binary tables were obsoleted by the
hash implemenation, and they need to be removed now so that they
don't become yet another feature bloat that people insist on
having around forever for backwards compatibility.
Assuming that the table is ordered is forbidden by the table API
and has been since Robert Thau created it, explicitly because
the intention was to replace the implementation with a table.
If you want an ordered table, then use the array types directly.
Now is the time to weed out what isn't being used.
....Roy
Re: cvs commit: apr/tables apr_tables.c
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Jan 20, 2001 at 04:03:05PM -0800, rbb@covalent.net wrote:
>...
> Sure they do. Take a look at apr_table_add, that just adds another
> element at the end of the table, and then I can call apr_table_do, and
> iterate over them, or I can get the elements directly and iterate over
> them.
The implementation allows for it, sure. But the table was intended to be a
hash. And hash table semantics don't provide for ordering.
> > 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?
>
> Nobody uses them because they were just added at the beginning of 2.0, and
> nobody has gone through the code yet to see where they are useful.
They were added prior to hash tables. I bet those "useful" spots would be
more useful as a hash table :-)
I see no conceivable need for the binary table, so there is no need to
multiple-path our code with text and binary tables and hashes. Drop the
bloat, drop the maintenance, etc.
>...
> As far as why do we need them, with the hash implementation, why do we
> need text tables anymore? They are the same basic thing, and the hash
> implementation can provide for both text and binary data, so couldn't
> everything be implemented as a hash table?
Absolutely. I would toss the text tables, too... if I could :-) But that
data type is just too ingrained and widespread. Nobody was touching binary
tables, so it is easy to toss them and refer users to hash tables instead.
> Regardless, since people in the group have wanted binary tables for over
> two years,
Their needs are met by the new hash table that Tony did.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apr/tables apr_tables.c
Posted by rb...@covalent.net.
> > 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.
Sure they do. Take a look at apr_table_add, that just adds another
element at the end of the table, and then I can call apr_table_do, and
iterate over them, or I can get the elements directly and iterate over
them.
> 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?
Nobody uses them because they were just added at the beginning of 2.0, and
nobody has gone through the code yet to see where they are useful. I seem
to recall that people were talking about making the request_rec->notes
table a binary table so that binary data could be passed between
modules. Beyond that I would need to actually investigate the code a bit
more.
As far as why do we need them, with the hash implementation, why do we
need text tables anymore? They are the same basic thing, and the hash
implementation can provide for both text and binary data, so couldn't
everything be implemented as a hash table?
Regardless, since people in the group have wanted binary tables for over
two years, it would have been very nice if this had been discussed before
they were simply removed. I would go search the archives for all the
times Lars and Dirk mentioned needing binary tables, and where they wanted
them, but searching our archives isn't easy right now, and I am in the
middle of other work. I'll try to find it later tonight.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apr/tables apr_tables.c
Posted by Greg Stein <gs...@lyra.org>.
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/
Re: cvs commit: apr/tables apr_tables.c
Posted by rb...@covalent.net.
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?
I knew exactly what you did, and I disagree with it. People have been
talking about the binary table implementation for at least two years, and
as soon as we got it, you just removed it without asking.
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.
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.
I am still -0.5 for removing the binary table implementation, and I am
leaning towards -1.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apr/tables apr_tables.c
Posted by Greg Stein <gs...@lyra.org>.
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?
Cheers,
-g
On Sat, Jan 20, 2001 at 09:15:30AM -0800, rbb@covalent.net wrote:
>
> > > > yes, you *will* use a hash instead. any questions can be directed to Bubba.
> > >
> > > ????? A hash and a table are two different things and both are
> > > useful. How do I insert data into a hash and iterate over it in the exact
> > > same order?
> >
> > apr_table_t is a list, but we don't insert. Hashed tables can't be iterated.
> > There needs to be something in between for some classes of data.
>
> Hmmm... What do you mean we don't insert into a table? There is an
> apr_hash_next function to allow us to iterate over the hash table, but of
> course the data is now out of order.
>
> > > I would really have appreciated if this change had been discussed at some
> > > point before an entire type was just removed.
> >
> > Ack, although we aren't using it right -now-, I'm -0.5 on this change
>
> -0.5 from me too. We may not use it, but this API has been being talked
> about since I joined this list over two years ago. By removing it I
> believe we have taken a step backwards. :-(
>
> Ryan
>
> _______________________________________________________________________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apr/tables apr_tables.c
Posted by rb...@covalent.net.
> > > yes, you *will* use a hash instead. any questions can be directed to Bubba.
> >
> > ????? A hash and a table are two different things and both are
> > useful. How do I insert data into a hash and iterate over it in the exact
> > same order?
>
> apr_table_t is a list, but we don't insert. Hashed tables can't be iterated.
> There needs to be something in between for some classes of data.
Hmmm... What do you mean we don't insert into a table? There is an
apr_hash_next function to allow us to iterate over the hash table, but of
course the data is now out of order.
> > I would really have appreciated if this change had been discussed at some
> > point before an entire type was just removed.
>
> Ack, although we aren't using it right -now-, I'm -0.5 on this change
-0.5 from me too. We may not use it, but this API has been being talked
about since I joined this list over two years ago. By removing it I
believe we have taken a step backwards. :-(
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apr/tables apr_tables.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: <rb...@covalent.net>
Sent: Saturday, January 20, 2001 10:19 AM
> > gstein 01/01/20 03:34:32
> >
> > Modified: include apr_tables.h
> > tables apr_tables.c
> > Log:
> > yes, you *will* use a hash instead. any questions can be directed to Bubba.
>
> ????? A hash and a table are two different things and both are
> useful. How do I insert data into a hash and iterate over it in the exact
> same order?
apr_table_t is a list, but we don't insert. Hashed tables can't be iterated.
There needs to be something in between for some classes of data.
> I would really have appreciated if this change had been discussed at some
> point before an entire type was just removed.
Ack, although we aren't using it right -now-, I'm -0.5 on this change
Re: cvs commit: apr/tables apr_tables.c
Posted by rb...@covalent.net.
On 20 Jan 2001 gstein@apache.org wrote:
> gstein 01/01/20 03:34:32
>
> Modified: include apr_tables.h
> tables apr_tables.c
> Log:
> yes, you *will* use a hash instead. any questions can be directed to Bubba.
????? A hash and a table are two different things and both are
useful. How do I insert data into a hash and iterate over it in the exact
same order?
I would really have appreciated if this change had been discussed at some
point before an entire type was just removed.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apr/tables apr_tables.c
Posted by rb...@covalent.net.
On 20 Jan 2001 gstein@apache.org wrote:
> gstein 01/01/20 03:34:32
>
> Modified: include apr_tables.h
> tables apr_tables.c
> Log:
> yes, you *will* use a hash instead. any questions can be directed to Bubba.
????? A hash and a table are two different things and both are
useful. How do I insert data into a hash and iterate over it in the exact
same order?
I would really have appreciated if this change had been discussed at some
point before an entire type was just removed.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------