Re: [PATCH] GIterator

[Daniel Elstner <daniel elstner gmx net>]

Am Sam, 2002-06-08 um 11.03 schrieb James Henstridge:
> 
> First, I would like to say that I would really like to see something 
> like this in glib.  Once they are available, you find all kinds of uses 
> for them.  Some things that seemed difficult become trivial and easy to 
> read with a good iterator implementation.

Yes.  The C++ STL uses iterators as the glue between containers and
algorithms.  A lot of algorithms for every purpose exist -- such as
std::for_each(), std::count(), std::transform(), std::sort() etc.  I
don't want to get too much into the details here, though.  But perhaps
GLib could provide some kind of generic algorithms too.

> Also, iterators are very simple to use (and usually almost as easy to 
> code).  Unlike loops such as gtk_container_foreach() where you need to 
> structure your code to fit into the container's loop, an iterator leaves 
> the user in charge of program flow.  They can stop the iteration any 
> time they want (simply by not asking for any more elements, and 
> destroying the iterator).

This is an important point.  Since C has no exception handling (and
setjmp() longjmp() is of course considered evil), there is no way to get
out of a foreach() loop prematurely.  Thus any error handling will be
hackish -- i.e. by setting a flag and ignoring all remaining elements.

> In my opinion, keeping the iterator interfaces as simple as possible is 
> a good idea.  If things are too complex, no one will implement iterators 
> and the API won't be very useful.  I think having single pass, 
> non-copyable iterators that are dynamically allocated is the way to go. 

This is, unfortunately, exactly the opposite of the STL's iterator
approach :(

>  This is similar to what python provides and if I understood danielk 
> correctly, matches one of the C++ iterator interfaces.

It matches the input_iterator concept, which is the simplest kind of
iterators the STL supports.

> >o People linking libgobject should be able to take advantage of GValue.

That would be nice.  We already have a complete GValue wrapper in
glibmm.

> Yep, it would be good to see something like this in glib.  Providing 
> some standard iterators (such as iterate over GList, etc) should help 
> people move existing code over to interfaces that use iterators, while 
> still being able to switch over to a more efficient implementation later on.