Re: Memory leaks
- From: David NeÄas <yeti physics muni cz>
- To: John Emmas <johne53 tiscali co uk>
- Cc: gtk-app-devel-list <gtk-app-devel-list gnome org>
- Subject: Re: Memory leaks
- Date: Thu, 10 Feb 2011 23:13:26 +0100
On Thu, Feb 10, 2011 at 07:28:40PM +0000, John Emmas wrote:
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.
And others, Gtk+ devs probably including, consider this a useful
optimisation â and in many cases a necessity. You still do not seem to
accept even the existence of this point of view.
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.
Remember we are talking about program-wide facility setup. How exactly
you release GQuarks or static registered types (not instances!)? What
objects are deleted? You do not want GTypes to be teared down if no
object of this type exists because then two subsequent GTK_TYPE_WIDGETs
might evaluate to different GTypes. The same applies to the logging
system: if it registers handlers, opens files or whatever, this is
program-wide. The âobjectâ that holds the memory is the main program â
and when that's deleted the memory surely goes away too.
While I agree having a clean-up function could be useful in some cases
(dynamical modules with GUI) this âwidespread expectation in C++â stuff
is just rubbish.
Yeti
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]