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 06:45:23 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:

  ->next_sibling  (->next and ->prev might be okay, but I like _sibling on
  ->prev_sibling   there for clarification that this is a tree)

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!"

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.


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

View raw message