Re: GLib data structures



        I had a quick lecture of your article, especially the hash table
part, which I was most interested in. I hope I haven't skipped the
essentials.

        It'd be nice to have some detailed explanation of chained hash
tables (this is the GLib implementation). Also, some words on choosing a
fast/good hash function with regards to the hash table's uniform
distribution. The reader must understand that it's vital for a hash table
not to have long lists in any bucket. This could be useful:
http://burtleburtle.net/bob/hash/doobs.html.

        Also, if possible, a chapter on binary trees. One of my
still-unanswered questions is "how to properly clean up a tree ?". The
docs on gtk.org aren't pretty clear on that. They suggested moving each
desired element to a list and then using that list for removing the
elements from the tree, which is clearly unconvenient for large sets of
data. For example, I have a GTree which gets filled with about 100k
elements per second. The elements must expire in at most 20 seconds. Of
course, there'll be a lot of them to remove. This might generate a very
large hash table. What's the proper way to manage this ?

        There also could be something added about the threading
implementation in GLib. The implementation, how it scales across multiple
processors, the (dis)advantages over POSIX threads and/or GNU PTH,
etcetera.

        I also would love to see a chart of differences between the 1.x
and 2.x trees of GLib. What has changed, is the 2.x branch faster or not.

        Finally, I think that you should bring to front the importance of
using GLib data types for portability across different types of hardware
platforms.

        I hope I won't get misunderstood. I see the above issues as things
that would be good to add to the documentation. So far I'm very pleased
with it. I was pleased to see that there finally existed some papers that
gave the newbie programmer the chance to quickly start developing without
the necessity of hacking through the GLib sources searching for answers
(my case).

        Keep up the good work !

----
If it's there, and you can see it, it's real.
If it's not there, and you can see it, it's virtual.
If it's there, and you can't see it, it's transparent.
If it's not there, and you can't see it, you erased it.



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