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

[Karl Nelson <kenelson ece ucdavis edu>]

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

My problem with owens argument is that last time I checked there
was not a full set of algorithms for manipulating a gqueue like a 
glist,  thus there is no glist equivalent with O(1) tail and no
one is likely to replace uses of glist where is was used with
lots of appends in gtk+ already.  Thus is is only a token effort
to correct the problem.  

The problem I see with the whole glib structure is that often
the concept of what is the list and what is a place in the list
are confused.  It should have been designed so that the first
argument to all list operations was a pointer to a list abstraction.
This could contain head/tail as well as pointers to allocator and
interator routines.  That would have allowed abstractions of the list
rather than this transparent structure.

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

Well, whether you hide it or not the information has to be somewhere.  
Glib chose not to have more that one node type for a simple list.  
This how do you store a head and tail description with just 3 void*?
If it is a circular structure and the data field is allowed to be arbitrary
you need at least one other flag to denote the head and tail element.  
Unfortunately, if you allocate a bit your will end up allocating an aligned
word.  This is why I just used another void*.  The space is going to get
allocated and you might as well make it compatible.
  
> 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?

Yes, it always is.  But glib was built to be so transparent that
it can not accept new types without breaking tons of code.  Within 
the limit of not breaking old code there is very little that can 
be done.

Again, this is just the opinion of a C++ coder... 

--Karl