Re: to GList or not to GList?

[Carlos Pereira <carlos pehoe civil ist utl pt>]

> i've implement linked-lists about a million times, but i'm still confused.

> The GList structure is stored separately from the data.  What is the
> rationale for this organization?  Is it mainly for GINT_TO_POINTER & friends?
> To contrast, here is a linked-list implementation that must be embedded in
> the data object (see MIME attachment).  For example,
>
>  struct mydata {
>    pe_ring peer;
>    pe_ring queue;
>    gint hits;
>    gint priority;
>  };
>
> In some cases, this organization seems like a better fit for the problem.
>
> Ignoring the question of API freezes, would such an embedded list be appropriate
> for inclusion in glib?  Or is this style of design generally a bad idea?

In my opinion, the whole beauty of lists, the truely elegant
way of handling lists, is to completely separate data from the 
list itself, as in glib, as in the slist, dlist examples below, 

because you can use the same lists for many different things, 
for just everything. So instead of implementing hard-coded lists 
a million times, you just have to build them once, a flexible, 
solid infra-structure, that you can easily adapt to different 
problems and programming languages.

However, in my opinion, it is a bad ideia to rely on
glib to supply your list needs, unless you are writting
a small app. The core of an application should not deppend 
of glib, which primary purpose is to support gtk needs.
If you change the GUI toolkit, the inner core, the engine 
of your program, should remain the same. Yes, this means
to have your own lists in the code, not those supplied
by the GUI toolkit.

Carlos

typedef struct _app_slist {
void *data;
struct _app_slist *next; } app_slist;

typedef struct _app_dlist {
void *data;
struct _app_dlist *next, *before; } app_dlist;