On 10 Feb 2011, at 17:48, Michael Torrie wrote: > > I guess we're at an impasse then. The discussion has now moved from the > definition of "leak" to some personal idea of what "beauty" is.
In which case, maybe we should agree to use the word "leak" for the simple purpose of identifying the characteristic we're discussing and not in any derogatory sense. To me, the debate has become something very simple.... when a program needs to allocate a block of memory only once, does the programmer necessarily have to release it programmatically or can he defer it to the OS? Remember we aren't specifically discussing memory that needs to persist for the lifetime of the program. Take my earlier example of g_message(). When you issue a g_message you have no way of knowing whether or not another g_message will follow later. And yet the allocated memory gets held open for the entire lifetime of the program. Some of the contributors here (me included) believe that this is just plain sloppy. Others aren't too bothered by it. Neither view is inherently right or wrong but it's clear there are as many devs holding one viewpoint as hold the other. So an optional counterpart to gtk_init() would seem to be an obvious way of pacifying both camps (or at least a good starting point, since that's where many of the leaks seem to originate).. The $64,000 question is whether anyone would make the effort to write it. Given the very large number of leaks (remember, 'leaks' is no longer a derogatory term!) finding them is bound to be a daunting task. But if it isn't done now it sure as hell won't get any easier to do in the future. If those aren't persuasive enough arguments for implementing such a function, there's another much more compelling argument - namely, gtkmm. In C++ programming there's a widespread expectation that when you delete an object it should release the memory that got allocated for it. If it doesn't there needs to be a very good justification for not doing so. IMHO, saying "Sod it, leave it to the OS" doesn't even come close to being a good justification. John _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
