Exam 70-483 Programming in C#

[NSforSG]

I hope I can pass this exam! Working hard on this now.

Any advice, discussion is much appreciated. But try not to bash or mock at me, for this is my first external programming language exam. (I mean, even if you want to, or eager to, laugh at me, I also LLST...)

 

[NSforSG]

I have a question to ask.

According to the book I read, it says "If the class has only unmanaged resources, but no managed resources, then the class should implement IDisposable interface and have a destructor, since the method Dispose() may not be called at all during the execution of the program."

Why is it that we still need to implement IDisposable interface for classes with only unmanaged resources? Can we just do without implementing that interface and have a destructor only?

 

[davidktw]

I have a question to ask.

According to the book I read, it says "If the class has only unmanaged resources, but no managed resources, then the class should implement IDisposable interface and have a destructor, since the method Dispose() may not be called at all during the execution of the program."

Why is it that we still need to implement IDisposable interface for classes with only unmanaged resources? Can we just do without implementing that interface and have a destructor only?

Well I'm not very much into C#, but this is more of a SOP rather than a language design. Apparently C# wanted to differentiate that badly between managed and unmanaged resources and wanted to give developers the power to decide which resources are to be explicitly release via the SOP of a IDisposable interface thru the dispose method. The whole concept could very well be done without an interface and having developers told please use "cleanUp" method if you want to release resources used by this class explicitly. They merely form the community concept of such SOP via the IDisposable interface.

Those "unmanaged" resources are still suppose to be implemented in the destructor when your object is finally freed by the GC. This is necessary unless you are interested in dangling resources in your long term application that can't be freed, once the last reference to your object is gone.

There are cases where you may not have the opportunity to call the dispose method explicitly, but you will still want your resources held by the instance to be remove upon it's life expectancy ends. The destructor and the finalize method is your point of no return.

 

[NSforSG]

Well I'm not very much into C#, but this is more of a SOP rather than a language design. Apparently C# wanted to differentiate that badly between managed and unmanaged resources and wanted to give developers the power to decide which resources are to be explicitly release via the SOP of a IDisposable interface thru the dispose method. The whole concept could very well be done without an interface and having developers told please use "cleanUp" method if you want to release resources used by this class explicitly. They merely form the community concept of such SOP via the IDisposable interface.

Those "unmanaged" resources are still suppose to be implemented in the destructor when your object is finally freed by the GC. This is necessary unless you are interested in dangling resources in your long term application that can't be freed, once the last reference to your object is gone.

There are cases where you may not have the opportunity to call the dispose method explicitly, but you will still want your resources held by the instance to be remove upon it's life expectancy ends. The destructor and the finalize method is your point of no return.

Maybe it's just really the SOP. The way I interpret is that perhaps the object that own the unmanaged resources still not yet going to cease but the user wants to release the resources so that another object or something can use it. Hence, the object calls the Dispose() method once all references to the unmanaged resource have been removed.

(maybe like someObj = null; ?)

But when implementing the Dispose() method, they also call this method GC.SuppressFinalize(this), which is confusing to me, as the object may own another unmanaged resource after disposing the first unmanaged resource.

maybe my interpretation is wrong?

 

[davidktw]

Maybe it's just really the SOP. The way I interpret is that perhaps the object that own the unmanaged resources still not yet going to cease but the user wants to release the resources so that another object or something can use it. Hence, the object calls the Dispose() method once all references to the unmanaged resource have been removed.

(maybe like someObj = null; ?)

But when implementing the Dispose() method, they also call this method GC.SuppressFinalize(this), which is confusing to me, as the object may own another unmanaged resource after disposing the first unmanaged resource.

maybe my interpretation is wrong?

There are a few cases why an instance will want to release it resources, to be used by another object is one possible scenario. The more common scenario is less baggage for the whole system. Sometimes the resources could be graphics memory or context for drawing. If your object doesn't need it anymore since it's going out of context, the release explicitly will be better, even though this graphical object may want to continue persist for cases like saving to persistent storage or just remaining dormant in the system.

Understand that releasing all references to an object doesn't necessary result in garbage collection. GC runs on it's own timing and only when a object freed from all strong references when selected for deallocation where the destructor will be involved. This can be a long time after your last reference to the object is removed.

So setting a reference to an object to null, which release the last reference to the object doesn't directly invoke the destructor. This part is the same as the Java GC system.

From what I read in the MSDN IDisposable API. Both the finalise method and the dispose method are to implement the removal of all resources held by the instance. From the method name GC.SuppressFinalize(this). It seems to instruct the GC not to invoke the finalize method on the object so that there is no double release of resources which is already taken care by the dispose method - verified here at https://msdn.microsoft.com/en-us/library/system.gc.suppressfinalize(v=vs.110).aspx