Re: Gtk-- refcounting question




Brian Alexander Martin <briam@cats.ucsc.edu> writes:

> Something else that seemed to me like it would be an issue is that with
> the current implementation, that unless you explicitly call delete on
> something, the c++ part of the object will not get destroyed (unless you
> use stick them on the stack as local data)
> 
> Here's the current implementation of Gtk_Style::unref
> 
> void Gtk_Style::unref(void)
> {
>   gtk_style_unref(gtkstyle);
> }
> 
> It seems to me that something like this would help:
> 
> void Gtk_Style::unref(void)
> { 
>   if(gtkstyle->ref_count == 1)
>     delete(this);
>   else
>     gtk_style_unref(gtkstyle);
> }
> 
> since ~Gtk_Style calls gtk_style_unref itself, both Gtk_Style and gtkstyle
> should get freed.  This should also work for static data because there    
> should always be a reference to it from the function's stack frame (until
> the function returns that is.  The destructor would get called in this
> case, correct?)

This does not work, because if somebody else has a reference count,
then Gtk_Style::unref will be fooled, and the C++ object will be
leaked. What should be done is that they Gtk_Style should keep
track of its own reference count, and hold a _single_ reference
count on the GtkStyle.

Gtk_Style::new()
{
   refcount = 1;
   gtkstyle = gtk_style_new(); // creates with reference count of 1
}

Gtk_Style::new(GtkStyle *style)
{
   refcount = 1;
   gtkstyle = style;
   gtk_style_ref (gtkstyle);
}

void 
Gtk_Style::ref(void)
{
  refcount++;
}

void 
Gtk_Style::unref(void)
{
  refcount--;
  if (refcount == 0)
    {
       gtk_style_unref (gtkstyle);
       delete (this);
    }
}


(Assuming that delete(this) is safe - I don't know what the
final decision was on that - I know that CORBA uses

  CORBA::release()

instead of member functions, possible for that reason)

Regards,
                                        Owen



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