Re: [gtk-list] Re: Gtk-- refcounting question
- From: Brian Alexander Martin <briam cats ucsc edu>
- To: gtk-list redhat com
- Subject: Re: [gtk-list] Re: Gtk-- refcounting question
- Date: Wed, 4 Mar 1998 11:06:29 -0800 (PST)
On 4 Mar 1998, Tero Pulkkinen wrote:
> Brian Alexander Martin <briam@cats.ucsc.edu> writes:
> > I've got a question about the current status of refcounting in gtk--.
>
> It could be better :)
>
> I think current situation is that the C++-parts of the gtk objects are
> not destroyed when container keeping the objects is destroyed. This is
> something that absolutely needs to be fixed. (This is why there's
> message in the web page asking people to use new instead of local
> scope for storing objects that are inserted to containers - that use
> of the objects can certainly be preserved when the refcounting is
> fixed, it might break the objects in local scopes)
>
> I dunno exactly how it should be solved... We'll see. Probably should
> make some way for C++ to handle all the refcounts...
>
This is a problem becuase the children of a container are kept using the C
interface, correct? And there's no way to get to the C++ wrapper from
that. Otherwise we could just call unref() on each of it's children..
Maybe I'm just missing something, but I don't see how haveing C++ handle
the refcounts would help.
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?)
-Brian
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]