Re: Cautions with g_list_next()

[tomas tuxteam de]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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...
[...]
>       element = g_list_next(members->list)
>
>       would "make 'element' point to the next member found in the GList 
> 'members->list'", just as
>
>       element = g_list_first (members->list)
>
>       means "make 'element' point to the first member [...]

Yes, I see: g_list_next dealing out all elements of the list one after
another. But to have that, you need another layer of complexity,
because...

  suppose you have two functions, f1 and f2, each one moving along the
  list on their own pace:

    f1(list):
      if(user clicked here) print g_list_next(list);

    f1(list):
      if(user clicked there) print g_list_next(list);

  Note what happens? When f1 gets called, it advances "the list" and
  spoils f2's world.

So we'd need a kind of handle for this movement. That's what usually is
called an iterator. For a list it would look more or less like

  GListIterator iter = g_list_iterator_new(list); /* Not really! */

With this, you might do first and next as you dreamt of. And f1 and f2
could just use their own iterators. If you misuse "the list itself" as
an iterator, you'll be always sentenced to have just one iterator per
list.

You will see iterators on more heavy-weight structures, such as a
GTKTreeModel. For a GList it seems like overkill (besides, this
box-and-pointer idiom for lists is so commonplace that the abstraction
layer will *usually* rather stand on your way instead of being helpful).

Of course, ymmv.

Regards
- -- tomÃs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFFB6Q+Bcgs9XrR2kYRAjajAJ9/Jbbap/SzCGhqZTOKUtBKJtOQVACZAXFo
7qi5Cj4wUmCfU1ReEs38iiM=
=Sw0l
-----END PGP SIGNATURE-----