Re: Memory leaks

[John Emmas <johne53 tiscali co uk>]

On 10 Feb 2011, at 01:19, Costin Chirvasuta wrote:

> I'm not saying this is really important and it should be done soon.
> I'm merely stating that the value of having gtk_cleanup() would be
> greater than zero. That is, regardless of how much trouble it would be
> for someone to write, if it would end up in the codebase it's value
> would be greater than the code bloat it would produce. A lot of people
> are using GTK and some definitely want it.

I'd like to add my support to that statement though arguably, it's of greater importance in gtkmm.  There's a 
common assumption with object oriented code that it should clean up after itself, which is of course the 
assumption I'd made (wrongly, as it now seems) in my original example.  Remember that it was gtkmm code in my 
example, not straight gtk+.  That's why I assumed there shouldn't be so many leaks being reported.  I can't 
agree with this though:-


On 10 Feb 2011, at 00:43, Michael Torrie wrote:

> The issue is whether a library intended for one-time loading should clean up after
> itself.  Whether we're talking 64 KB or 4 GB, cleaning up every one-time
> allocation is still a waste of time.

Not really.  *Something* needs to perform the cleanup operation so if the app did it on shutdown, the OS 
(presumably) would take correspondingly fewer cycles to unload the app.  And remember, we're talking about 
OPTIONAL functionality here.  NOT offering the option results in a far greater waste of programmer time.  
Remember this comment from a user of Valgrind:-


On 9 Feb 2011, at 17:01, James Morris wrote:

> Not only do we have to write our own code, we have to put work into
> making other peoples code ignore the errors in other peoples code so
> we can see the errors in our own code. It's a bloody outrage!

I've never used Valgrind but I can fully understand how frustrating that would be and how unproductive.  
Surely everybody agrees that tracking down genuine leaks in one's code is a good and desirable thing?  And 
surely everybody agrees that having to jump through hoops like that in order to achieve it is an unproductive 
waste of the programmer's time?  Full marks to Valgrind for providing the feature - but it shouldn't excuse 
sloppiness by other developers.

I think there's a compelling case for some kind of optional gtk_end() or gtk_unload() type of function - 
especially given that gtk is now object oriented through the mechanism of gtkmm.  In fact, in the case of 
gtkmm, Gtk::Main() could possibly just have an extra parameter to signify whether its d'tor should clean up 
or not.

John