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