On Fri, 17 Jun 2011 10:43:24 +0200 Tadej Borovšak <tadeboro@xxxxxxxxx> wrote: > > Since the documentation says it's a newly allocated string, I have > > always freed the string when I no longer need it. This hasn't > > produced any ill effects so far. Usually, valgrind will catch > > problems related to freeing pointers to non-heap memory. > > Another indicator that returned value should be freed is lack of const > modifier on return value. > > If API docs state: > > const char * get_something () -> do not free result > char * get_another_thing () -> free result This is certainly not true of the C language: in the C language, naming a variable as const has no effect on whether its storage may or may not be freed where it happens to be allocated on the heap, and the same is true of C++ (the delete expression may happily to applied to pointers to const, or indeed const pointers to const). Furthermore, I do not believe it to be a convention adopted by GTK+/glib either. Apart from the case of C strings, I believe GTK+ eschews any use of the const keyword in order to avoid const poisoning. I am happy to be proved wrong, but I cannot off the top of my head recall any case, other than a C string, where an object is returned in GTK+ by pointer to const. The only rule to apply is to see if the documentation says whether ownership is retained by GTK+/glib, or whether an object must be freed or (in the case of a GObject unrefed). Sometimes the documentation states this, and sometimes it doesn't. Where it doesn't, it is necessary to look at the source. Chris _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
