Re: GObject reference counting / lack of "sink" issue
- From: Dave Benson <daveb idealab com>
- To: Tim Janik <timj imendio com>
- Cc: Owen Taylor <otaylor redhat com>, Gtk+ Developers <gtk-devel-list gnome org>, Andrew Paprocki <andrew ishiboo com>
- Subject: Re: GObject reference counting / lack of "sink" issue
- Date: Sat, 1 Oct 2005 08:40:56 -0700
On Fri, Sep 30, 2005 at 01:38:40AM +0200, Tim Janik wrote:
> you are right, GObject is widely used these days out of GtkObject contexts,
> and anywhere in C land (where memory book keeping or reference house keeping
> can't be automized) when objects are created and ownership is passed on,
> a floating flag is strongly desired (and forces you to derive and
> reimplement
> if you're consequent enough ;)
while i think that the floating flag is a good idea,
i'm pretty skeptical about its addition at this point...
in particular, such an addition doesn't modify
the api per se, but certainly modifies "best practice".
for example, users will have to choose whether certain
methods sink or not, and it won't be possible to modify
existing api to be consistent.
to take an example: g_value_set_object().
once you add a floating flag, it'd be tempting
to assume that you can safely:
g_value_set_object(value, g_object_new(...));
but changing set_object to sink would break api.
and, in my opinion, there already has been invented
a nice enough solution to this problem:
g_value_take_object(value, g_object_new(...))
if you are implementing a container class simply have
my_container_take_object(container, child);
and
#define my_container_add_object(container,child) \
my_container_take_object(container,g_object_ref(child))
which will actually be more efficient
than a bunch of bit-twiddling, and probably easier to understand.
- dave
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]