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/memory/unix apr_sms.c apr_sms_std.c apr_sms_tracking.c
Date Fri, 08 Jun 2001 10:09:25 GMT
On Fri, Jun 08, 2001 at 11:09:39AM +0200, Sander Striker wrote:
> Greg Stein wrote:
> > On Fri, Jun 08, 2001 at 12:32:04AM -0400, Cliff Woolley wrote:
>...
> > > "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...

Yes (sorry), and sure...

> > 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.

I'm not sure that I follow. We have a complete set of navigational pointers:
parent, child, prev, next. With those, I'm not sure what you mean by a "list
header".

Insertion as a child of "this" is:

    new->parent = this;
    new->next = this->child;
    if (new->next != NULL)
        new->next->prev = new;
    this->child = new;

Removal is:

    if (this->prev != NULL)
        this->prev->next = this->next;
    if (this->next != NULL)
        this->next->prev = this->prev;
    if (parent->child == this)
        parent->child = this->next;

Is it that you are you saying that the third condition of the removal is
unnecessary with the "ref" scheme?

> 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.

If you don't mind, could you elaborate? I'm confused on what you mean here.

> 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 :-)

You can focus on whatever you'd like. While you're doing that, we'll sneak
in and change the names, make tweaks to the code, etc. Remember: the code
can be attacked by more than one person :-)

Cheers,
-g

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

Mime
View raw message