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 10:22:49 GMT
[..]
> > 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?

Yes, that's exactly what I'm saying.

> > 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 we are always inserting at the head of the list it has less
of an impact. Didn't occur to me before, but does now.

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

Ack. I know that. There are multiple people working on sms actually :-)
Go ahead on the name change. I think noone likes extra typing :-)

Sander


Mime
View raw message