[Gtk-sharp-list] widget destruction

[Lluis Sanchez Gual]

El dc 09 de 03 de 2011 a les 10:54 -0500, en/na Nicholas Frechette va
escriure:
> On Wed, Mar 9, 2011 at 6:39 AM, Lluis Sanchez Gual
> <slluis.devel at gmail.com> wrote:
>         Subclasses may need to free their own unmanaged resources,
>         which may not
>         be related to gtk at all. For example, I could implement a
>         widget
>         subclass which pinvokes a C api to get some data, which has to
>         be
>         explicitly freed. I would free that data in the finalizer, but
>         since the
>         finalizer will not be called if the object is explicitly
>         disposed, I
>         also have to free that data in the Dispose method. So, I will
>         end having
>         a DeleteMyData method which is called from the finalizer and
>         from
>         Dispose.
>         
>         The Dispose pattern provides an standard solution to the above
>         scenario.
>         It states the need for a Dispose(bool disposing) method, to be
>         called
>         from Dispose and from the finalizer. The 'disposing' parameter
>         is 'true'
>         when calling from Dispose, meaning that it is safe to access
>         other
>         reference objects, and it is 'false' when called from the
>         finalizer,
>         meaning that only unmanaged data should be accessed.
>         
>         There is some documentation about this pattern here:
>         
>         http://msdn.microsoft.com/en-us/library/b1yfkh5e.aspx
>         
>         
>         
> 
> I disagree strongly with the implicit destruction of managed resources
> through the use of that pattern and the finalizer. Having worked
> extensively on embedded systems where tight control over memory is
> always required, in my experience, it is always better to provide
> tools for programmers to fix bad usage than it is to brush it under
> the rug and do their job for them. The finalizer should be there only
> to warn that memory is leaking and if you must, free that memory, but
> the warning is key so that the code can be fixed. Finalizers add a
> cost that can be very hard to measure.

I have no experience in embedded systems, so I can't tell much about it,
but I'm pretty sure that the kind of applications you can build with
GTK# don't have the same memory constraints that an embedded system has.
So forcing developers to micro-manage the memory of the application when
in many cases the GC would do the job just fine looks a bit unproductive
to me.

Lluis.