Re: freeing GTK+ memory

On Sat, 18 Oct 2008 00:00:01 +0200
Pablo Yanez Trujillo <yanezp informatik uni-freiburg de> wrote:
> thanks, that's what I wanted to know. But I have some more questions:
> 1. Does the behaviour (about 'floating' references) also apply for
> (gtk+) objects created with g_object_new instead of gtk_object_new?

It applies to any object derived from GInitiallyUnowned.  You need to
look at the inheritance tree of the object you are creating.  If this
is a home-made GObject you will know how you derived it.  If it is an
object supplied by GTK+ then look at the GTK+ documentation, which
documents the inheritance tree of every GTK+ class.
> 2. The GtkObject documentation says: "Never call g_object_unref()
> unless you have previously called g_object_ref() ..", however in the
> "HelloWorld" example of the TreeView tutorial [1] Tim writes:
>   GtkTreeModel        *model;
>   ...
>   model = create_and_fill_model (); /* function creates a ListStore
> with gtk_list_store_new */
>   gtk_tree_view_set_model (GTK_TREE_VIEW (view), model);
>   /* The tree view has acquired its own reference to the
>    *  model, so we can drop ours. That way the model will
>    *  be freed automatically when the tree view is destroyed */
>   g_object_unref (model);
> ...
> Is this correct? Or it is safe to do so since gtk_tree_view_set_model
> implicit g_object_ref() call?

It is correct and safe.  Classes implementing the GtkTreeModel
interface, such as GtkListStore, are pure GObjects which do not derive
from GInitiallyUnowned.  This means that they are created with a
reference count of one and no floating reference. The call to
gtk_tree_view_set_model() will cause the tree view object to take
ownership of the model - that is, it will increment the reference count
of the model by one.  The purpose of calling g_object_unref() is to
cause the model to be destroyed at the same time that the tree view
object owning it is destroyed. If that is not what is intended (that is,
the tree model should outlive the tree view), then the call should not
be made.

> Is there a document(ation) which describes more precisely how
> Gtk+/Glib manages the memory of the objects  (I mean about those
> 'floating' references, etc)?

The reference I gave you tells you pretty much all you need to know,
but the following GObject documentation (under "Description") says more
or less the same:


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]