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

>  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

>  The problem I see with the whole glib structure is that often
>  the concept of what is the list and what is a place in the list
>  are confused.  It should have been designed so that the first
>  argument to all list operations was a pointer to a list abstraction.

Glib lists are designed to be like Lisp lists.  The STL way is not the
only way possible.


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