Re: [gtk-list] Re: Freeing data connected to a widget via signals...

[Thomas Mailund <mailund mail1 stofanet dk>]

>>>>> "M" == Matthew D Allen <s2mdalle@titan.vcu.edu> writes:

 M> Now pretty much the only other memory issue I have with GTK+ is
 M> how and when it chooses to allocate new memory for the purpose of
 M> returning a value.  I.e. if you do gtk_editable_get_chars() it
 M> returns dynamically allocated memory, which you have to g_free()
 M> after you use, but with some other widgets, you really shouldn't
 M> free the result of functions that return the widget's "contents"
 M> because instead of newly allocated memory, it's just returning one
 M> of the widgets fields.  I tend to think of it conceptually, as in,
 M> "this function returns malloc'd memory when you ask for the
 M> contents of the widget, and here's a similar function (different
 M> widget) that doesn't return malloc'd memory (or at least not
 M> memory you should free)".  Conceptually, they're both functions
 M> that "return something that's 'in' the widget".

Yup, I second that this should really be documented somewhere, but as
a general rule I asways free everything that isn't declared 'const'
(and which isn't a GtkWidget*).  I don't know how great a rule this
is, but it hasn't caused be any grief so far.  As for GtkWidget* I
ref them if I'll save them somewhere else, otherwise I don't care
about them.

 M> Any chance of those types of things ending up in the RDP?
 M> (generally, when I free the return value of a GTK+ call when I'm
 M> done with it, I only did it because I checked out the gtk+ source
 M> and saw that it was g_strdup'ing a value on return.  Something
 M> like return(g_strdup(widget->field));

well, when in doubt consult the source.  If you discover something
which you think should be documented, document it ;)  It is really the
only way it will get documented.

        /mailund