Re: Floating references

7.06.2017 09:45 Tristan Van Berkom <tristan vanberkom codethink co uk> wrote:

On Tue, 2017-06-06 at 23:32 +0200, Rafal Luzynski wrote:
6.06.2017 22:28 Chris Vine <vine35792468 gmail com> 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.

Sorry, my typo or too fast thinking. Of course I meant GInitiallyUnowned
object which become owned by the containers. Of course, a reference is the
way that some objects own other objects but g_object_ref_sink() makes
a special kind of ownership, I'll call it an exclusive ownership. It differs
from the regular ownership because it can be called only once, it does not
increase the reference count, and its corresponding g_object_unref()
is supposed to ultimately deallocate the object.

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, [...]

Yes, this is an example of a regular reference (or a regular
non-exclusive ownership).

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.

That's true, child-container relationship is just an example, the same
concept may be used for other purposes, too.

While at this, I'd like to tell that your another post explains the
problem thoroughly and IMHO completely. Thank you for this.



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