Re: Upcoming GLib changes

[Jeff Garzik <jgarzik pobox com>]

(sigh; no checked-out copy of glib ATM)

Tim Janik wrote:
> the GQueue implementation
> -------------------------
[...]

Sounds good.


> 3) g_queue_index (), g_queue_push (), g_queue_pop () and g_queue_peek ()
>    have no place in the g_queue API, since they are either not standard
>    queue operations or are already available with g_queue_push_tail (),
>    g_queue_pop_head ().

I forget what _peek() does.  See comments about GStack WRT _index().  I
think the _push/pop() routines are useful shortcuts but since they
conflict with the usage of those verbs in GStack, they should definitely
go.


> the GStack implementation
> -------------------------
> 
> probably all of the major GLib hackers have been thinking about implementing
> a GStack structure at some point (or have actually been doing such a thing,
> my stab at this was for instance in fall '97) and figured that all the
> neccessary bits are already provided by GSList.
> the current g_stack_ API is merely a bad wrapper (macros don't give verbose
> warnings about NULL pointers and treating a non existant stack as an
> empty one is simply wrong) over some of the GList functions for no apparent
> benefit. apart from that, things like g_stack_index() are simply not
> stack conforming operations, if you think about using such a function,
> be assured that you would have wanted to use a linked list in the first
> place. a sane stack implementation would expose: stack_push, stack_pop,
> stack_empty and maybe stack_peek, all of which is readily available
> with slist_prepend, slist_remove (slist_delete_link),
> slist == NULL and slist ? slist->data.

I consider GQueue and GStack incomplete for one reason:  I couldn't
decide whether to make the structures opaque or not, and never got any
feedback on the subject from anybody.

If the structures are opaque, GQueue and GStack should get the same API
as GList and GSList.  If not, then functions such as g_queue_index()
need not exist.

As to GStack's existence, it can be made a good wrapper.  GStack
implementation is small and makes the code cleaner and more readable. 
ie. you need not determine from program behavior that a GSList is being
used as a stack (because such usage is often not commented or obviously
used as such).  Stuff like this saves code analysis time when you are
reading lots of code.




> GList & GSList
> --------------
> the recently added g_list_delete () function should be named
> g_list_delete_link (), and of course, we need a GSList implementation
> for that as well (the GList and GSList implementations and API should
> always stay in sync).

Did you guys go through the API and notice any other differences?

How about a minimal g_alloca in GLib?

	Jeff




-- 
What would Brian Boitano do?