apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@samba-tng.org>
Subject RE: cvs commit: apr/memory/unix apr_sms.c apr_sms_std.c apr_sms_tracking.c
Date Fri, 08 Jun 2001 09:09:39 GMT
> On Fri, Jun 08, 2001 at 12:32:04AM -0400, Cliff Woolley wrote:
> > On Fri, 8 Jun 2001, Sander Striker wrote:
> >
> > > Oh, yes, I actually want to do s/mem_sys/sms/ aswell, but that can
> >
> > I'm hoping that includes the foo_mem_sys's that are in the apr_sms_t
> > structure?  "sms->parent_mem_sys" etc seems both redunant and too much
> > typing.
>
> Exactly. Completely agree.
>
> > "sms->parent" would be ideal, but then again "sms->ref" wouldn't
> > make much sense
>
> They should be:
>
>   ->parent
>   ->next_sibling  (->next and ->prev might be okay, but I like _sibling on
>   ->prev_sibling   there for clarification that this is a tree)
>   ->child
>
> The "ref" concept is wrong. What is really happening is a standard
> doubly-linked list. However, it adds an indirection and different
> terminology. As a result, a new reader must crawl through a bunch of code
> just to say "oh! a doubly-linked list!"

To say it is wrong is a bit blunt don't you agree? I've used this scheme
many times before and it has never failed me. Lets call it different...

> Screw that. Just make it a true doubly-linked list. Keep everybody happy.
>
> Removal is simply:
>
>   if (sms->prev_sibling != NULL)
>       sms->prev_sibling->next_sibling = sms->next_sibling;
>   if (sms->next_sibling != NULL)
>       sms->next_sibling->prev_sibling = sms->prev_sibling;
>
> Done. Nothing fancy or complicated, and everybody will know what
> is going on upon first glance.

Yes, but you are missing something here. You would have to create
a list header to nest in the apr_sms_t structure. With the ref
concept you don't need that, because it can point to parent->child.

And although for removing from a list it is almost the same
number of operations, for inserting into a list you have more.
Anyhow, same idea, different approach. Since the only place this
is used is inside the sms framework code could we please leave it
be for now? I'd like to focus on some other stuff first :-)

About the renaming:

     parent_mem_sys     -> parent
     child_mem_sys      -> child
     sibling_mem_sys    -> sibling
     ref_mem_sys        -> ref     /* since ref_mem_sys was a confusing name
                                    * anyway. Add a comment for now to
explain
                                    * what it does.
                                    */
     accounting_mem_sys -> acct


Sander


Mime
View raw message