Re: reference count not freed in dispose?



On Fri, 2008-12-12 at 14:13 +0200, markku vire iki fi wrote:
> Hi,
> 
> Since the unreffing is done in finalize, it will not happen more than once
> (finalize is called once, destroy can take place more often).
> 


> If somebody else may be holding reference to your (internal) object, then
> making unref in destroy is important, since this allows breaking reference
> loops. When this is not the case (you have not published the internal object
> in any way), then it doesn't matter in practise.
To the renderer, the object is not internal. It is settable via
'adjustment' property.

If someone supply a GtkAdjustment with a reference to the redererer in
data fields, there will be a circular reference. In common practice it
is OK, but it is not always going to be OK.

Yu
> 
> Cheers,
> 
> -Markku-
> 
> Quoting Philip Withnall <philip withnall gmail com>:
> 
> > Yes, and priv->adjustment should be set to NULL afterwards to stop it
> > getting unreffed more than once. Please file a bug.
> >
> > Philip
> >
> > On Fri, 2008-12-12 at 00:41 -0500, Yu Feng wrote:
> >> Hi,
> >>
> >> I was reading gtkcellrendererspin.c
> >> and saw:
> >>
> >> static void
> >> gtk_cell_renderer_spin_finalize (GObject *object)
> >> {
> >>   GtkCellRendererSpinPrivate *priv;
> >>
> >>   priv = GTK_CELL_RENDERER_SPIN_GET_PRIVATE (object);
> >>
> >>   if (priv && priv->adjustment)
> >>     g_object_unref (priv->adjustment);
> >>
> >>   G_OBJECT_CLASS (gtk_cell_renderer_spin_parent_class)->finalize (object);
> >> }
> >>
> >> Isn't it suggested that the reference counts should be freed in dispose
> >> method in GObject's document?
> >>
> >> Yu
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> gtk-devel-list mailing list
> >> gtk-devel-list gnome org
> >> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
> >
> 
> 
> 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list



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