On Tue, 6 Jun 2017 21:23:09 +0200 (CEST) Rafal Luzynski <digitalfreak@xxxxxxxxxxxxxxxxx> wrote: > 6.06.2017 11:50 Stefan Salewski <mail@xxxxxxxxxxxx> 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 to zero the element is deleted. But when a > > newly created element just has ref count zero, where is the > > problem? > > Let's consider a system where a newly created object has ref count > zero. Assume that you have created an object but changed your mind and > decided you want to delete it. Then just do what g_object_unref() would do, were the count to be 1: finalize/free any members requiring it and then free the object itself. > g_object_unref() raises an assert > if ref_count is not > 0. But OK, this assert would have to be removed. > So having ref_count == 0 you can't delete the object because ref_count > is already 0. Or if you allow ref_count to be decremented, as > ref_count is of type guint it would become 0xFFFFFFFF rather than -1. > > Then assume that g_object_ref() was called once. The next balanced > g_object_unref() would make the object deallocated. You would have > to call g_object_ref() immediately after creating to make sure the > object exists until you decide to deallocate it. > > With floating object you can (you have a choice): > > - ref/unref the object any number of times as long as the number > of unrefs is never greater than the number of refs, > - give an ownership to a container and forget the unref (the container > will take care of it), > - unref the object to delete it. > > It looks like a good design to me. Even if a better system can be > designed I believe it would not be much better and therefore not > worth reworking. In my present state of ignorance, I don't buy it. No one is suggesting reworking. This is no more than intellectual interest in the original design choice. _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
