Re: [Evolution-hackers] [maybe OT?] Code excerpts from Evolution

[Tom Copeland <tom infoether com>]

On Tue, 2005-05-03 at 10:38 +0530, Not Zed wrote:
> This isn't quite right.  It doesn't use a gtree to track the chunks,
> it uses it to calculate the unused chunks.  Subtle difference - in
> that the tree is used as a one-off structure during the clean process,
> not as long-term tracking structure.

Many thanks!  OK, I've updated that mention:

http://infoether.com/~tom/evolution_snippets.html

> We actually don't use g* collections for many things we might, because
> of efficiency & preference issues. 

Yeah, I'd noticed that... I was kind of surprised!

> e.g. edlist is a double-linked list implementation which has O(1)
> append and prepend, and O(1) removal of head and tail nodes.  GList
> has O(N) append and O(N) removal of the tail node.  This often leads
> to unecessary and inefficient code such as g_list_reverse, or having
> to manually track the tail node which is prone to coding mistakes. 

Argh.

>  It also means you can't re-use the same simple code as a stack, a
> queue, or an ordered list without a performance penalty in some of the
> cases - there are even more special api's for each case.

GQueue is a bit of an odd one; I was surprised to see all those insert
and remove functions.  Seems a bit unqueueish....

> In general, the glib collections: 
>       * have inconsistent interfaces, e.g. g_ptr_array_add vs
>         g_*array*append, g_list_free vs g_hash_table_destroy,
>         g_list_nth vs g_array_index, g_list_length vs
>         g_hash_table_size, etc. 

Heh, yes, very true, I'm making sure to note those in the tutorial.  

>       * most of the interfaces are over-designed - glist has 30
>         functions and 2 macros. 
>       * are not very well implemented, generally each is implemented
>         separately with no overlap (glist vs gslist, g*array vs
>         gstring), or the overlap and 'subclassing' is funny (e.g.
>         g*array). 

Yeah, GPtrArray and GByteArray are declared inside GArray... rather odd.

>       * cannot be subclassed or extended in any way.  not even
>         internally!  e.g. GQueue vs GList. 
>       * often can only be iterated using callbacks, without iterators,
>         making some code much more complex and less efficient than
>         needed (e.g. requiring one-off callback data structures to be
>         written).  A particularly bad case is GHashTable. 

Hm, I found those kind of handy... especially when you could pass, say,
g_free to foreach.  But I haven't been using them very long...

>       * provide zero type safety.  At least if the base structures
>         could be extended they could provide some type safety.  e.g.
>         edlist provides data node type safety at least by having each
>         usage 'subclass' the next/prev node pointers structure. 
>       * aren't as flexible and efficient as they might be.  e.g. you
>         often store a hashtable key+data pair where the data contains
>         the key, or it can be calculated from the data.  So you end up
>         wasting a pointer storing a duplicate of the key pointer.  Or
>         worse, where you store an integer as the data pointer which
>         has portability as well as type issues. 
>       * I could probably go on ...

Hey, what do you think about GRelation :-)  I searched far and wide
before I found code that used it...

> To put it bluntly, glib's data structures 'mostly suck', but they're
> there, and usually simple to use, so we use them sometimes.

Fair enough,

Yours,

Tom