Mathias Hasselmann wrote:

GList has similar problems:

        * It doesn't know the type of its elements, which makes
        re-factoring of of GList code quite a pain. It's really easy to
        change the element type of some list at one place and to forget
        it at some other place.

Well, I'm not really sure how you'd implement this sanely without either a) having a mess of macros, or b) having to specify the type every time you change the list -- and even then, all you can do is check to make sure the sizes match (not very useful for storing pointer).

Alternatively, there could be a GObject-ified list type that only allows you to put GTypes in... in that case, sure, you get type checking for 'free'. Of course, then you couldn't store pointers to structs in this list type without boxing them, which is kinda annoying.

        * Since GList doesn't know its element type, elements have to be
        released manually which forces you to repeat this code sequences
        over and over again:
g_list_foreach (l, (GFunc) g_free, NULL);
                g_list_free (l);

Yeah, that's a bit of annoying, but could just add a define to glib for this:

#define g_list_destroy(list, freefunc)  G_STMT_START{ \
    g_list_foreach((list), (GFunc)(freefunc), NULL); \
    g_list_free((list)); \

Since you will always have to tell GList how to free its elements (whether on list creation or destruction), this seems reasonable to me. Again, with a GObject-ified list type, this wouldn't be necessary; it would of course always know how to free itself.

Not sure if you're suggesting deprecating GList, but given the massive amount of code in the wild that uses it, that seems foolish to me.

One of the things I've found lacking in glib/gobject (ever since I started doing Mac Cocoa development) is a set of data structures that take refcounted objects. NSArray, NSDictionary, etc. are often much nicer to use simply because you don't have to worry much about the memory management of the objects you stick in them. ... But this might be a bit out of the scope of what you're suggesting here (or maybe not?).

(I think your array suggestions are pretty nice, though I don't have the time to comment atm. A little concerned about more magic macros, though.)


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