>>>>> "M" == Matthew D Allen <[EMAIL PROTECTED]> 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
--
To unsubscribe: mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
