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 > <[email protected]> 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. _______________________________________________ Gtk-sharp-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
