Could someone please explain to me what it means for something to be "IDisposable"? Does that have something to do with weak references?? What are they and why do they exist?
And why isn't there a destroy method on any objects in C# ???
![Photo](http://www.gravatar.com/avatar/8dbfea916e2c2b6fce0fe40a04805932?s=100&d=http%3A%2F%2Fforums.netduino.com%2Fpublic%2Fstyle_images%2Fmaster%2Fprofile%2Fdefault_large.png)
Disposability
Started by Charles, Nov 21 2010 10:50 PM
3 replies to this topic
#1
Posted 21 November 2010 - 10:50 PM
#2
Posted 22 November 2010 - 03:33 AM
It means that the object implements the IDisposable interface. It also means that the object will have a public method called Dispose() that can be explicitly called to release any acquired resources (i.e. pins) or implicitly called when the object is referenced in a "using" statement in C#. The "using" statement calls Dispose() automatically when execution reaches the end of the "using scope" (indicated by the closing curly brace).
What this means in Netduino programming is that when the Dispose() method is called on your object, it no longer has control over the Netduino pin. You can no longer read or write to that pin using that object. You are free to create new objects that refer to that pin.
Google for the "Dispose pattern" for more detailed information.
There are C++ style destructors in C#. They are called "finalizers" and they use the same syntax as a C++ destructor i.e. ~Classname(). Finalizers are different from destructors in that they are called non-deterministically on the "finalizer" thread of the process. Finalizers are called when the object is collected by the .NET Framework garbage collector. You cannot control when (or if) they are called.
I am not certain if finalizers have a role in NETMF programming. Someone else might know.
#3
Posted 22 November 2010 - 03:43 AM
This is how I started learning about it:
http://forums.netdui...ch__1#entry4293
#4
Posted 22 November 2010 - 04:18 AM
Regarding weak references, they are a mechanism for maintaining a reference to an object but not interfering with its eligibility for garbage collection.
If I hold a strong reference to an object, it will never be collected. On the other hand, if I hold a weak reference to an object, the object can become eligible for collection (for example, if there are no strong references to it in the system).
Why this is useful: let's say you wanted to write your own version of String.Intern(). You would want the following pseudocode:
If myMagicMap acted like a normal hashtable, it would never lose any entries. It would grow without bound, and would continue to store strings that the rest of the system long ago stopped caring about. What you really want is a magic hashtable structure that holds onto entries only as long as they exist somewhere else in the system. There are really only two sensible ways to do this: using finalizers, and using WeakReferences.
The problem with using finalizers is that you would have to modify each class' code to make it work (and, anyway, Bill Gates won't allow you to modify System.String). The approach using WeakReferences is much more elegant. Doing so is possible although not 100% straightforward. You can't just make a naive implementation using the Hashtable from the standard library due to the tendency for WeakReference targets to wink out of existence.
If I hold a strong reference to an object, it will never be collected. On the other hand, if I hold a weak reference to an object, the object can become eligible for collection (for example, if there are no strong references to it in the system).
Why this is useful: let's say you wanted to write your own version of String.Intern(). You would want the following pseudocode:
public static string MyIntern(string s) { string canonical; if(myMagicMap.TryGetValue(s, out canonical)) { return canonical; } myMagicMap.Add(s); return s; }
If myMagicMap acted like a normal hashtable, it would never lose any entries. It would grow without bound, and would continue to store strings that the rest of the system long ago stopped caring about. What you really want is a magic hashtable structure that holds onto entries only as long as they exist somewhere else in the system. There are really only two sensible ways to do this: using finalizers, and using WeakReferences.
The problem with using finalizers is that you would have to modify each class' code to make it work (and, anyway, Bill Gates won't allow you to modify System.String). The approach using WeakReferences is much more elegant. Doing so is possible although not 100% straightforward. You can't just make a naive implementation using the Hashtable from the standard library due to the tendency for WeakReference targets to wink out of existence.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users