glib bindings and memory management

[Colin Walters]

There are a lot of issues in this discussion, but let me try to state
what I consider essential and we'll see what follows from that.

In particular I feel fairly strongly that "a{s?}" must map to
GHashTable, or we haven't actually gained a lot from the glib bindings
except that stuff is allocated using g_malloc and variants are GValue,
which to me is nearly negligible.

So what follows from that?  If the GHashtable cut n' paste won't work,
then we can't do the whole magic one-malloc-block trick.  If we can't do
that, we need to define a protocol for destruction.  

Let me come up with a concrete proposal here.  We define some
special-case mappings as follows (where ? refers to a basic type and .
refers to any type):

"as" -> char **, null-terminated, freed with g_strfreev

Then there are these general mappings:

"a{?.}" -> GHashTable, freed with g_hash_table_destroy
"a." -> GArray
"(.)" -> C structure, freed with g_free
"v" -> GValue

This does mean that if for example you have method which returns a value
of this type:

a(sva{ss})

A client programmer would have to write something like this code:

typedef struct { char *name; GValue *val; GHashtable *table; } FooValue;

GArray *arr;
int i;
if (!com_foo_Method (proxy, &arr, &error)) exit(1);

/* do stuff with arr */

for (i = 0; i < arr->len; i++) {
   FooValue *elt = &(g_array_index (arr, i]));
   g_free (elt->name);
   g_value_unset (elt->val);
   g_hash_table_destroy (elt->table);
}

The destruction code having to be written by each client is kind of
unfortunate, but it seems worth it to get the natural feel of GHashtable
and char ** (which should be much more common cases).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/dbus/attachments/20050504/7fe4cbe9/attachment.pgp