On Nov 30, 2007, at 2:09 PM, Matthew Barnes wrote:
What about embedding a GList node at the top of a larger struct, as we do with GObjects? e.g. struct MyNode { GList parent; ... other data ... };Sure you'd have an unused 'data' pointer in every node, but it might bepossible to use a subset of the GList and GQueue APIs that only manipulate GList pointers (not the 'data' pointer) and avoid the need for a bunch of list macros.
Sure, you *can* make it work, if you only use the GList primitives that don't try to allocate or free a node. You can use g_list_concat() to prepend and append, g_list_remove_link() to remove, and if you make sure to set the data pointer to point back to the containing object, you can actually use g_list_sort(), g_list_reverse(), and g_list_foreach().
But, since the GList API normally *does* allocate and free nodes for itself, code doing this will generate a bit of cognitive dissonance that can and will create bugs. I wouldn't do it in real code because of that, but as the attached file shows, well, you can do just about anything if you put your mind to it...
Attachment:
evilglist.c
Description: Binary data
On the other hand, it might not be so bad to have a separate API that provides these list node primitives, as macros or inlines, to use to build such things internally.
-- zella (crying): I want... us: What? zella (still crying): I want... something!