On Wed, Sep 19, 2001 at 09:55:56PM -0700, Justin Erenkrantz wrote:
> On Wed, Sep 19, 2001 at 09:48:30PM -0700, Brian Pane wrote:
> > Following the pattern of the apr_hash_t iterator is fine with me, too.
> >
> > But I just noticed a small problem with the apr_hash_t iterator:
> >
> > APR_DECLAR
On Wed, Sep 19, 2001 at 09:48:30PM -0700, Brian Pane wrote:
> Following the pattern of the apr_hash_t iterator is fine with me, too.
>
> But I just noticed a small problem with the apr_hash_t iterator:
>
> APR_DECLARE(void) apr_hash_this(apr_hash_index_t *hi, const void **key,
>
Ian Holsman wrote:
On Wed, 2001-09-19 at 14:28, Justin Erenkrantz wrote:
On Wed, Sep 19, 2001 at 12:25:36PM -0700, Brian Pane wrote:
The original approach that I posted was a traditional iterator object:
typedef struct apr_table_iter_t apr_table_iter_t;
apr_table_iter_t * apr_table_iter_make(apr_
William A. Rowe, Jr. wrote:
[...]
In the case of tables, the minimum api I would accept includes a duplicate
and truncate function. Also (of course) the existing add, as well as an
insert (since we loose the ability to do so with this change.)
Insert? For a table, insert==add, because it's an uno
From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
Sent: Wednesday, September 19, 2001 4:38 PM
> On Wed, Sep 19, 2001 at 02:33:22PM -0700, Ryan Bloom wrote:
> > Which philosophy would that be?
> >
> > Tables have worked this way for a very long time. Take a look at the docs
> > in apr_table.h:
> >
On Wed, 2001-09-19 at 14:28, Justin Erenkrantz wrote:
> On Wed, Sep 19, 2001 at 12:25:36PM -0700, Brian Pane wrote:
> > The original approach that I posted was a traditional iterator object:
> >
> > typedef struct apr_table_iter_t apr_table_iter_t;
> > apr_table_iter_t * apr_table_iter_make(ap
On Wed, Sep 19, 2001 at 02:33:22PM -0700, Ryan Bloom wrote:
> Which philosophy would that be?
>
> Tables have worked this way for a very long time. Take a look at the docs
> in apr_table.h:
>
> /* This has to be first to promote backwards compatibility with
> * older modules which cast
On Wednesday 19 September 2001 02:28 pm, Justin Erenkrantz wrote:
> On Wed, Sep 19, 2001 at 12:25:36PM -0700, Brian Pane wrote:
> > The original approach that I posted was a traditional iterator object:
> >
> > typedef struct apr_table_iter_t apr_table_iter_t;
> > apr_table_iter_t * apr_table_i
On Wed, Sep 19, 2001 at 12:25:36PM -0700, Brian Pane wrote:
> The original approach that I posted was a traditional iterator object:
>
> typedef struct apr_table_iter_t apr_table_iter_t;
> apr_table_iter_t * apr_table_iter_make(apr_pool_t *p,
> const ap
Greg Stein wrote:
On Wed, Sep 19, 2001 at 11:07:37AM -0700, Brian Pane wrote:
...
If not, I still would like to replace apr_table_elts with a different
interface that doesn't make any promises about apr_table_t being
an apr_array_header_t. That will enable us to fix the performance
in later releas
On Wed, Sep 19, 2001 at 11:07:37AM -0700, Brian Pane wrote:
>...
> If not, I still would like to replace apr_table_elts with a different
> interface that doesn't make any promises about apr_table_t being
> an apr_array_header_t. That will enable us to fix the performance
> in later releases withou
11 matches
Mail list logo
