On Fri, Oct 20, 2000 at 10:09:37AM +0200, Alexander Larsson wrote:
> In this particular case you need the foo object reference to see when
> you've passed the end of the array, but often (as in the case of
> lists, which are probably the most used enumerator) you don't need that,
> but only a single pointer. Then you could get away with less allocations
> and dereferences.
I do see your point about allocations, but for the list
enumerator, almost anyone would use the convenience funcs, and therefore
it's hidden from the creator and the caller.
As for dereferences,
get_next(gpointer *context)
{
cont = *context;
my_thing = (MyThing *)cont->something;
}
get_next(gpointer context)
{
header = (GList *)context;
elem = (GList *)header->data;
}
So dereferences are about the same (the second example is from
my list convenience stuff.
I guess the question is one of opacity vs convenience. Note
that the user_data you pass to any gtk_signal_connect() is something you
can't get the pointer to. Meaining, that you would need to do the same
things in the signal handler that you have to do in my current
implementation as far as header structures, etc. The signal handler is
signal_handler(GtkWidget *widget, gpointer user_data), not
signal_handler(GtkWidget *widget, gpointer *user_data), right?
That said, the person's has_more/get_next functions do have to
keep sane state, whether they much with their own pointers or the
GEnumeration's pointer. I guess if others feel like you do, it isn't
that bad.
> This is easily fixed by freeing the enumerator list elements while
> enumerating. That is a good optimization anyway.
Yeah, that's probably a good idea.
Joel
--
"In the room the women come and go
Talking of Michaelangelo."
http://www.jlbec.org/
jlbec evilplan org
Attachment:
genumeration.diff.3.gz
Description: Binary data