Re: Cautions with g_list_next()

[David Nečas (Yeti) <yeti physics muni cz>]

On Wed, Sep 13, 2006 at 02:51:22AM -0300, Fabricio Rocha wrote:
> Hi, Yeti and Tom,
>
>       Yes, sure, your explanation is quite right and logic, and I could find 
> out how to make things work after dealing with the ->next member 
> directly... but I see some kind of "mislogic" that leads to this error 
> (I think probably more people did the same mistake someday). The GLib 
> has an "abstraction" principle which might lead one to understand that 
> the GList functions would allow the use of a GList element without 
> having to touch its pointer members directly.

No one need to deal with the next pointer directly.  You
just need to distinguish between the data structure and the
iterator if you think in STL...

The data structure does *not* contain any iterators.  As in
STL, iterators are external objects.  The only confusing
thing is that the iterator and the data structure is the
same type.

    GList *iter;

    for (iter = list; iter; iter = g_list_next(iter)) {
        /* use iter */
        ...
    }

Where do you have to use ->next?

> So, it might look like
>
>       element = g_list_next(members->list)

>       would "make 'element' point to the next member found in the GList 
> 'members->list'",

And it definitely *does* it.  It returns
members->list->next, the iterator for the next element.

> know what I mean?

You have the misconception GList* have some internal state
and internal iterators...

> This makes things a bit confusing. 
> That´s why sometimes I feel that the GLib and the GTK documentation 
> could be more detailed in some aspects, with some "do´s and don´t's"... 

...which I don't understand where you get from, as first, if
it was so GLib documentation would say it, second, it's
rather strange to think that something that can be perfectly
represented by NULL (and GLib does say NULL is an empty
list) has any kind of internal state.

Yeti


--
Anonyms eat their boogers.