Re: Floating references

[Rafal Luzynski <digitalfreak lingonborough com>]

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.
>
> No.
>
> 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.

Regards,

Rafal