Re: G_DEFINE_ARRAY, G_DEFINE_LIST

["Brian J. Tarricone" <bjt23 cornell edu>]

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)); \
} G_STMT_END

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.)

	-brian