Re: Memory leaks

[John Emmas <johne53 tiscali co uk>]

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