Re: CList glitch (some kind o off-topic response)

[Kaz Kylheku <kaz ashi footprints net>]

On 9 Nov 1999, Owen Taylor wrote:

> Date: 09 Nov 1999 10:26:46 -0500
> From: Owen Taylor <otaylor@redhat.com>
> Reply-To: gtk-devel-list@redhat.com
> To: gtk-devel-list@redhat.com
> Subject: Re: CList glitch (some kind o off-topic response)
> Resent-Date: 9 Nov 1999 15:27:35 -0000
> Resent-From: gtk-devel-list@redhat.com
> Resent-cc: recipient list not shown: ;
> 
> 
> leon@udmnet.ru writes:
> 
> > Karl Nelson wrote:
> > > 
> > > I have a fully compatible implementation of glist that does track
> > > tails.  (There does not need to be a new structure the current
> > > system could easily have been expanded.)
> > > 
> > > It changes the glist structure to
> > > 
> > >   struct GList
> > >     { void * data;
> > >       GList *next,*prev,*aux
> > >     };
> > > 
> > > Heads and tails are represented as before with NULLs in the next and
> > > prev,  however, now the aux pointer completes the circular linked list.
> > > All the algorithms for working through the lists still work without
> > > modification.
> > > 
> > >         next prev aux
> > > Head  { NEXT, 0, PREV }
> > > Body  { NEXT, PREV, 0 }
> > > Tail  { 0, PREV, NEXT }
> > 
> > Why simply not to link the head of the list to the tail, so making 
> > it circular, not linear? Have someone suggested this idea to glib 
> > maintainers? No structure change in list items at all. The only
> > (possibly) bad thing is if someone counts on NULLs in head and 
> > tail of list. But IMHO such programs are very few, and it is 
> > bad style to rely on internal representation. So I see no obstacles.
> 
> Any guesses to how many times code like:
> 
>  tmp_list = foo;
>  while (tmp_list) 
>    {
>      MyStruct *x = tmpl_list->data;
>      tmp_list = tmp_list->next;
> 
>       /* do something with x */
>    }
> 
> Occurs within GTK+? I don't have an exact count - but its certainly

Oops... that's why one should at the very least hide the ->next operation
behind a macro, which can produce a null pointer under the right
circumstances. The application should not know that there exists a member
called ``next'' within the list node and directly access it; it should be
``private''. That's called information hiding.

One possibility is to use an abstract list-specific nil pointer rather than
null:

	nil = list_nil(list);
	tmp = list_first(list);

	while (tmp != nil) {
	    /*...*/
	    tmp = list_next(tmp);
	}

With this interface, you iterate over any kind of list, since nothing is
revealed about its structure. Oh well, hind and lateral vision is always 20-20,
isn't it?