Re: g_list_prepend() vs g_list_append()

[Mark Mielke <mark mark mielke cc>]

On Sun, Sep 08, 2002 at 06:58:31PM +0800, James Henstridge wrote:
> >Seems like solving the problem, rather than requiring everybody to use
> >a workaround, might be prudent.
> A cyclic linked list/ring data type was discussed during the glib/gtk 
> 2.0 development cycle, but after the API freeze:
>     http://mail.gnome.org/archives/gtk-devel-list/2001-August/msg00417.html
> Maybe it would be worth looking at this again for 2.2 or 2.4?

GRing looks exactly like what I was suggesting. Looks like somebody has
already done it.

> By the way, if you want to efficiently append to a GList, you should 
> maintain a tail pointer.  When you want to append, g_list_append() to 
> the tail, and update the tail pointer.  There are a number of examples 
> of this in the gtk API.

Thanks for the suggestion. However, I am not looking for a solution
under the current scheme. I can hack solutions just as well as the
next guy. If I had such a problem, I would have posted to the user
list, not the devel list.

I do wish to contribute to GLIB (as opposed to Gtk), and the primary
fault I see with it, is that it is a little rough around the edges.
Definately an excellent library, in that it easily competes with many
other attempts currently available, however, it is still showing the
evolutionary path it took. An example for this is that GQueue looks
like an attempt at making GList more efficient for a very specific
application. It never took the next step of being generalized to what
GRing describes.

Cheers,
mark

-- 
mark mielke cc/markm ncf ca/markm nortelnetworks com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/