Web lists-archives.com

Re: Floating references

On Tue, 2017-06-06 at 23:32 +0200, Rafal Luzynski wrote:
> > 6.06.2017 22:28 Chris Vine <vine35792468@xxxxxxxxx> wrote:
> > 
> > [...]
> > GObjects not derived from GInitiallyUnowned are indeed weird, as I think
> > you are suggesting. They start with a reference count of 1 but without
> > an owner.
> As far as I understand owned object were supposed to be the widgets
> contained inside the containers. Not all widgets are contained (toplevel
> windows are not), also not all objects are widgets.


Owned objects are objects which one owns a reference to, the concept of
ownership is a bit hard to explain and follow, because it's hard to
differentiate (there is no real material difference, except in how you
write your code) from other references.

For instance, under the hood, g_signal_emit() will retain a reference
to the emitting object during signal emission, because it requires that
object to stay alive during the course of signal emission, but emitting
a signal can cause callback cycles to occur which result in releasing
the (otherwise) final references to the object.

I would say that g_signal_emit() holds a temporary reference, but there
is *usually* somewhere in a program where ultimately the calling code
expects to be the one who has the final reference to an object, this is
the ownership ref. If the program has no ref count imbalance bugs, then
releasing an ownership reference will *eventually* result in
finalization, once any other temporary references have gone away.

That said, ownership is not always a requisite, but strong references
are; I.e. programs can be constructed where some object is created and
given to a chain/group of objects or code segments, this is not a
regular case for normal OOP patterns.

So yes, container widgets own their children.

Other non-container widgets may also own delegate objects for doing
work, like completions and such.

Non widget / Non UI objects can create and own other delegate objects
for other reasons, completely unrelated to widget hierarchies.

Also, at the most basic level, when you do:

   foo = g_object_new(MY_TYPE_FOO);

You *own* the object, in the sense that ultimately that object is your
responsibility until you either give it away (by passing it as a
parameter and subsequently calling g_object_unref()) or, until you just
decide to dispose of that object by calling g_object_unref() without
ever sharing the object.

Ownership of objects is a requirement for garbage collection in
general, it is not exclusive to the case of GtkWidgets at all.


gtk-list mailing list