Some years ago I read about floating references as described in
https://developer.gnome.org/gobject/stable/gobject-The-Base-Object-Type.html
Of course that makes sense.
Newly created objects get ref count 1, but are floating. If they get
put into a container element, floating ref is converted
On Tue, 2017-06-06 at 11:50 +0200, Stefan Salewski wrote:
> Some years ago I read about floating references as described in
>
> https://developer.gnome.org/gobject/stable/gobject-The-Base-Object-Type.html
>
> Of course that makes sense.
>
> Newly created objects get
6.06.2017 11:50 Stefan Salewski wrote:
> [...]
> But I was wondering, why for newly created objects ref count is not
> just zero, so when the element is put into a container it is just
> increased to one.
>
> So there must be a reason why it can not work this way. Of course when
> ref count drops
On Tue, 06 Jun 2017 19:35:40 +0900
Tristan Van Berkom wrote:
> On Tue, 2017-06-06 at 11:50 +0200, Stefan Salewski wrote:
> > But I was wondering, why for newly created objects ref count is not
> > just zero, so when the element is put into a container it is just
> > increased to one.
>
> In a w
On Tue, 6 Jun 2017 21:23:09 +0200 (CEST)
Rafal Luzynski wrote:
> 6.06.2017 11:50 Stefan Salewski wrote:
> > [...]
> > But I was wondering, why for newly created objects ref count is not
> > just zero, so when the element is put into a container it is just
> > increased to one.
> >
> > So there mu
6.06.2017 21:41 Chris Vine wrote:
> [...]
> No one is suggesting reworking. This is no more than intellectual
> interest in the original design choice.
I wasn't around when this design choice was made so I can only
guess. I can only repeat what Tristan has already said:
this is a feature of GInit
the question is why pure
(non-GInitiallyUnowned) GObjects start with a reference count of 1,
instead of a count of 0 as in other similar implementations. Starting
with a count of 0 would have made floating references unnecessary.
Chris
___
gtk-list mailing
tart with a reference count of 1,
> instead of a count of 0 as in other similar implementations. Starting
> with a count of 0 would have made floating references unnecessary.
I can't tell for sure. Maybe (as I wrote before) the floating reference
feature was not always expected to exist,
Chris Vine wrote:
So I guess the question is why pure
(non-GInitiallyUnowned) GObjects start with a reference count of 1,
instead of a count of 0 as in other similar implementations.
CPython starts reference counts at 1, and it works perfectly
well -- the code that allocates the object initiall
On Tue, 2017-06-06 at 21:28 +0100, Chris Vine wrote:
> On Tue, 6 Jun 2017 22:10:39 +0200 (CEST)
> > Rafal Luzynski wrote:
> >
> > > > 6.06.2017 21:41 Chris Vine wrote:
> > >
> > > [...]
> > > No one is suggesting reworking. This is no more than intellectual
> > > interest in the original design
On Tue, 2017-06-06 at 23:32 +0200, Rafal Luzynski wrote:
> > 6.06.2017 22:28 Chris Vine 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 under
7.06.2017 09:45 Tristan Van Berkom wrote:
>
>
> On Tue, 2017-06-06 at 23:32 +0200, Rafal Luzynski wrote:
> > > 6.06.2017 22:28 Chris Vine wrote:
> > >
> > > [...]
> > > GObjects not derived from GInitiallyUnowned are indeed weird, as I think
> > > you are suggesting. They start with a reference c
12 matches
Mail list logo
