> if (1) > { > glocal_object GFile *file = g_file_new_for_path ("/tmp"); > glocal_string gchar *basename = g_file_get_basename (file); > g_debug ("Basename is '%s'", basename); > // look ma' no leaks! > }
This is, of course, cute but I don't think this would actually catch many of the non-trivial leaks that make it into the code base today. Those are typically not scope based -- possibly because the attention span of the average programmer is long enough to cover the writing of a whole function, ;-) The current serious leak cases I see are: * The dispose or finalize method of an object type fails to free some stuff. This is quite common. * Cyclical links. The resulting leaks are typically quite big. A case scope-based destructors would handle is this: * Multiple return statements, typically for error handling, where one or more branches forget to free stuff. Cursory valgrinding doesn't catch this because the code doesn't get exercised. The case isn't uncommon, per se, but programs don't hit the cases often. M. PS: The situation where scope-based destruction is important is for languages such as C++ with exceptions in use. C with GObject is not such a language. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list