After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 581106 - Associations and types of elements for arrays and hash tables
Associations and types of elements for arrays and hash tables
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2009-05-02 15:52 UTC by David Zeuthen (not reading bugmail)
Modified: 2018-05-24 11:51 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed patch (16.43 KB, patch)
2009-05-02 15:56 UTC, David Zeuthen (not reading bugmail)
none Details | Review

Description David Zeuthen (not reading bugmail) 2009-05-02 15:52:15 UTC
Hi,

One really neat thing about the base object class is that you can associate data with pointers, e.g. g_object_set_data() and g_object_get_data() and thereby hook into the finalization process through a GDestroyNotify.

This latter is extremely useful in mid-layer library code where you take objects from the library user, attach some stuff to them and return later with a callback.

It would be nice to have similar constructs on GArray, GPtrArray and GHashTable since these are (unfortunately) not based on GObject, e.g.

 g_array_set_data()
 g_array_get_data()
 g_array_steal_data()

and ditto for GPtrArray and GHashTable

In addition, it would be useful to know about the types of elements stored in these three container classes, e.g.

 GType g_array_get_element_type()
 GType g_ptr_array_get_element_type()
 GType g_hash_table_get_key_type()
 GType g_hash_table_get_value_type()

so you can write safer code like in [1].

Another example is where you e.g. want to return a collection to the user where you point into data that is already allocated. In that case you want to unref the allocated data when the user unrefs his reference to the collection. For example

 p = g_ptr_array_new ();
 g_ptr_array_set_element_type (p, G_TYPE_STRING);
 // add pointers to p that point into a DBusMessage
 g_ptr_array_set_data (p,
                       "dbus-1-message",
                       dbus_message_ref (message),
                       (GDestroyNotify) dbus_message_unref);
 // drop our ref, message will be unreffed, when p is unreffed
 dbus_message_unref (message);
 // return p to user, user will call g_ptr_array_unref() when done

Again, this is not specific to D-Bus; it's just to illustrate the general idea.

I'll attach a patch that does this for GArray - the idea is similar for GPtrArray and GHashTable but I thought I'd float the idea before doing that.

[1] : This is an example of where I want to use this for the proposed GDBus work but it's generally useful anyway.

static void
on_get_ata_smart_data_attrs_cb (DevkitDisksDevice *proxy,
                                GAsyncResult      *result,
                                gpointer           user_data)
{
  GPtrArray *ata_smart_attrs;
  GError **error;

  error = NULL;
  if (!devkit_disks_device_invoke_get_ata_smart_data_attrs_finish (
        proxy,
        &ata_smart_attrs,
        &error))
    goto fail_and_stuff;

  g_assert (g_ptr_array_get_element_type (ata_smart_attrs) ==
            DEVKIT_DISKS_TYPE_ATA_SMART_ATTR);

  /* do stuff with ata_smart_attrs */

  g_ptr_array_free (&ata_smart_attrs);

  <....>
}
Comment 1 David Zeuthen (not reading bugmail) 2009-05-02 15:56:27 UTC
Created attachment 133813 [details] [review]
Proposed patch

The macro thing for g_array_[get|set]_element_type() aint pretty but at least it is safe.
Comment 2 David Zeuthen (not reading bugmail) 2009-06-09 13:15:56 UTC
Ping. Any thoughts on this? Thanks.
Comment 3 Matthias Clasen 2009-06-11 04:37:39 UTC
Some comments:

- I'm not really thrilled about growing the size of each hash table, even when they don't have type information associated with it. What about this instead ?

void
g_hash_table_set_key_type (GHashTable *table, GType type)
{
  g_dataset_id_set_data (table, key_type_quark, type);
}

Theoretically, the locking overhead of this should be worse than your GData version, but from looking at the code, it seems to be the same.

- I'm not convinced the extra contortion with the macro in glib and the real implementation in gobject is really worth it. Would simply putting the set_type/get_type functions in gobject be ok ? We already do that with the types for hashtable and arrays. You can still refer to the functions in the docs...
Comment 4 Matthias Clasen 2009-07-10 17:25:30 UTC
David, any update ?
Comment 5 GNOME Infrastructure Team 2018-05-24 11:51:15 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/217.