g_clear_object() has been in glib since 2.28, and now g_clear_pointer() has landed in glib master (see bug #674634).
Their typical usage is to implement GObject::dispose, or “goto out” pattern, previously you would write:
void my_dispose (GObject *obj) { MyObject *self = (MyObject *) obj; if (self->priv->object != NULL) { g_object_unref (self->priv->object); self->priv->object = NULL; } if (self->priv->hash != NULL) { g_hash_table_unref (self->priv->hash); self->priv->my_hash = NULL; } etc... }
or:
void some_func () { GHashTable *tmp = NULL; ... if (error) goto out; tmp = g_hash_table_new(); ... out: if (tmp != NULL) g_hash_table_unref (tmp); }
But now those becomes:
void my_dispose (GObject *obj) { MyObject *self = (MyObject *) obj; g_clear_object (&self->priv->object); g_clear_pointer (&self->priv->hash, g_hash_table_unref); etc... }
or:
void some_func () { GHashTable *tmp = NULL; ... if (error) goto out; tmp = g_hash_table_new(); ... out: g_clear_pointer (&tmp, g_hash_table_unref); }
As extra bonus, g_clear_object() and g_clear_pointer() are thread-safe. That means that 2 threads can clear the same pointer at the same time and it will be freed only once. I’ve heard some code needs thread-safe dispose…
Thanks to Simon McVittie for the original idea in telepathy-glib where we had tp_clear_object/pointer for years.
So, *every* single free call does a bus-locking cmpxchg operation.
This isn’t exactly free. Are you sure this is a good idea?
Thanks for the heads up! I am going to start using g_clear_object from today. 🙂
@alexl: as you said on the bug, if you destroy with _unref() it’s going to use atomics anyway. But I can understand it’s not optimal to use with _free(). I personally don’t care about the thread-safe aspect, but that’s how g_clear_object() has been made since 2.28…
Well done!