Re: [gtk-list] Re: gtk_type_new, bug?



Owen Taylor <owt1@cornell.edu> writes:

> Mattias Gronlund <Mattias.Gronlund@sa.erisoft.se> writes:
> 
> > In gtk/gtktypeutils.c there is a funcion gtk_type_new(GtkType type) that
> > allocate some memory, but I can't find any function that will free that
> > memory. Shouldn't there be a gtk_type_destroy(GtkObject *object)
> > function
> > to complement gtk_type_new(GtkType type)?
> 
> Hmmm, I think the general attitude toward that is that once a type
> is created, it is created. You can't destroy a type because some
> of the information is stored statically in the widget implementations.

Hmmm^2, I think you are talking about two different things here.
Mattias thinks about objects, that is, instances of types; and Owen
thinks about the types themselves.

gtk_type_new allocates memory for a new instance of a type and
initializes it.  gtk_type_new can only really allocate GtkObjects, and
you destroy them by reducing their reference count to zero.
GtkWidgets are GtkObjects, too, so this applies to GtkWidgets as well.

The types themselves are dynamically created in Gtk+ with
gtk_type_unique.  Like Owen, I think there is no point in trying to
ever remove a type from the system.  We would not gain much and it is
probably very, very difficult to make this removal work at all.  You
can never be sure who will be using the type in the future.

As to memory leaks, I noticed one when stress testing the reference
counting patch, but I have not been able to find it.  Checkergcc
(similar to purify I think) did not report any garbage so I assume
that Gtk isn't really leaking any memory.  Maybe some memory_chunk
isn't properly reusing the freed memory or something.  As long as the
memrory is linked into the mem_chunk, checkergcc wont report it is
garbage.



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