Re: CList glitch (some kind o off-topic response)

On 09-Nov-99 Federico Mena Quintero wrote:
>>  My problem with owens argument is that last time I checked there
>>  was not a full set of algorithms for manipulating a gqueue like a
>>  glist,  thus there is no glist equivalent with O(1) tail and no
>>  one is likely to replace uses of glist where is was used with
>>  lots of appends in gtk+ already.  Thus is is only a token effort
>>  to correct the problem.
> If there is a portion of code in GTK+ that creates long lists by
> appending, and that code is not keeping its own tail pointer, then
> it
> should be considered buggy for lack of performance.  It should be
> fixed.

Fine, but what about users code?

For users to keep a tail pointer thay need to make assumptions about
the implementation of lists that GLib uses.

I don't agree with Owen that using list->next in code is OK when we
have a g_list_next() function for just that purpose.

It *is* possible to fix the GList implementation to provide O(1)
appending without breaking any code. Indeed, Owen, Karl and I have
discussed this at great length previously, but Owen wasn't convinced
by our argument.


I brake for chezlogs!

Go Bezerk!

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]