Re: [Proposal] GRing

[Tim Janik <timj gtk org>]

On 18 Aug 2001, Havoc Pennington wrote:

> 
> Joshua N Pritikin <vishnu pobox com> writes:
> > 
> > o GRing offers the space requirements of GList with the performance
> > characteristics of GQueue.  GQueue can be deprecated.
> > 
> 
> GQueue is new in 2.0, so we'd probably need to replace it, but it's a
> bit late in the release cycle for that.

right, unfortunately.

> What is the space advantage of GRing over GQueue? The node sizes are
> the same aren't they?

GRing is substantially easier to use. you don't need to keep
an extra Queue structure around, or update it when the GQueue
lists are modified with normal g_list functions.

> Did we discuss a ring-like API as an alternative when GQueue went in?

unfortunately not, if so, i'd rather have gone for GRing as it
is for the most part similar to GLists and doesn't need an extra
structure (GQueue) to be kept around. it still provides frequently
requested GList features, such as head/tail removal/insertions being
O(const).

also it's scope is more clearly defined, basically all API that we
provide for GSList/GList should also be provided for GRing, for
GQueue that's not so clear as pure queues should prolly just have
push/pop tail/head.

having used a variant of GRing for a couple of months in other projects,
i have to say that it's easier to use than GQeueue and can even replace
GList usage for most cases, as you seldomly come around the need to
walk a list without also knowing its head.

> 
> Havoc
> 

---
ciaoTJ