Thanks Joe, this was actually very helpful.
On Mar 19, 11:53 am, Joe Enos <[email protected]> wrote: > I've never done this myself, but I believe this component stuff and > the suppressing garbage collection all has to do with unmanaged > resources. It also adds a layer that ensures that Dispose() is not > called more than once. If you read through the MSDN notes of why > they're doing all of this, I'm sure there are valid reasons. However, > in my opinion, if you're defining something with only simple managed > types, then you should be safe doing it the short way - dispose only > what needs to be specially disposed, and let garbage collection handle > the rest of it. > > The "disposed" field that lets you ensure that it's only actually > disposed once is probably a good idea - you may want to at least > consider using that. In theory, no one will ever call Dispose() more > than once, assuming they're using a "using" block, but you can't > guarantee that other developers in the future won't do something > weird. > > On Mar 19, 8:05 am, Alon K <[email protected]> wrote: > > > > > And I forgot to add. The code I posted below also adds a 'components' > > instance, adding to the complexity of using Dispose. What is it and > > why do I have to add it, what does it do? > > > On Mar 19, 11:00 am, Alon K <[email protected]> wrote: > > > > So from what I understood - it isn't really necessary to implement a > > > long winded Dispose() definition like I found in most examples which > > > clears every member variable/class, I can just implement what I need > > > done in addition (for example you implemented "Save();") and the > > > garbage collection will take care of everything else (such as > > > releasing resources for the variable Success). > > > > This code snippet is from MSDN and is different from what you are > > > using. Can you explain the differences and why one would choose to use > > > this approach (or conversly your approach). This is the type of code I > > > see in almost every example online and what got me confused in the > > > first place. > > > > public void Dispose() > > > { > > > Dispose(true); > > > GC.SuppressFinalize(this); > > > } > > > > private void Dispose(bool disposing) > > > { > > > if(!this.disposed) > > > { > > > if(disposing) > > > { > > > component.Dispose(); > > > } > > > > // Do Stuff > > > > disposed = true; > > > } > > > } > > > > While using your example would just be: > > > > public void Dispose() > > > { > > > // Do Stuff > > > } > > > > On Mar 19, 10:22 am, Joe Enos <[email protected]> wrote: > > > > > IDisposible makes it easy to do what you're doing. The whole point of > > > > using it is so you don't have to explicitly call Dispose() - instead, > > > > you wrap your code around a "using" block. The using block will call > > > > Dispose() automatically at the end, or if an exception is thrown. > > > > > You can do whatever you want inside of Dispose() - close connections, > > > > save files, etc. The method itself is just a normal method, that can > > > > do anything any other method can do. It doesn't make the object > > > > itself null or automatically take it out of scope, but in most cases > > > > it does make the object unusable. As long as you create the instance > > > > properly, you won't have any problems. > > > > > Example: > > > > > using (MyClass myInstance = new MyClass()) { > > > > // Do stuff with myInstance} > > > > > // myInstance is now out of scope > > > > > is the same as: > > > > { > > > > MyClass myInstance = new MyClass(); > > > > try { > > > > // Do stuff with myInstance} > > > > > finally { > > > > myInstance.Dispose(); > > > > > } > > > > }- Hide quoted text - > > - Show quoted text -
