The Dispose Pattern is the be-all and end-all of resource deallocation - which is why we almost never use it. Many thanks to @harisimer for the German captions. Source code available at: github.com/JasperKent/Finalizers
I think that's about it for memory-management, so let me know what else you'd like to see. Source code at: github.com/JasperKent/Finalizers Remember to subscribe at ru-vid.com/show-UCqWQzlUDdllnLmtgfSgYTCA And if you enjoyed it, click the 👍.
Loved this video. I never fully undertood the pattern and you made it really simple to understand. I work with native graphics APIs (Vulkan, DirectX, OpenGL) so I need to release and dispose unmanaged objects constantly and you made the explanation pretty clear. Also, you covered netcore which is fantastic because there are a lot of old tutorials that only cover older versions of net framework. Thank you! Subscribed!
I had to go through the video twice and then when I tried the same in laptop. The concept is clean. Many thanks to you. This was the best explanation. I am not sure weather what using is covered in any other video or not, but that should be included in the same video. Also, what finally is.
Finally! (pun intended) I can get my head around the Dispose pattern and use it properly and I wasn't aware that Visual Studio provided a handy snippet, very helpful.
Hey thank you for making these good tutorials, I really love and enjoy watching your explanations. It's really good. Do you have any videos where you covered how managed and unmanaged code could be distinguished n C# ?
So if client code forgets to use a using statement (or call Dispose manually) then when garbage collection happens Dispose is called on any managed objects implementing IDisposable (Also presuming the GC doesn't call Dispose twice and knows when it has already been called)?
Not quite. When garbage collection occurs, managed objects are deleted and there is no need to call Dispose on them because Dispose only deals with other managed objects, which would be in the process of being deleted anyway. Imagine a chain of objects A->B->C, where C has an unmanaged resource (like a file handle). A.Dispose() calls B.Dispose() and B.Dispose() calls C.Dispose() which closes the handle. Thus when A.Dispose() is called by the client code (either directly or through using) the chain is followed and ultimately the handle is closed. However, if the client code forgets to Dispose then the garbage collector deals with all three objects individually, regardless of the fact that there is any chaining between them. C.Finalize() is called directly by the garbage collector and there's no need to follow the chain to get to it, and so ne need to worry about A and B because they don't have finalizers.
@@CodingTutorialsAreGo Thanks makes sense. I suppose if someone wrote a class with an unmanaged class level resource and cleaned that up in Dispose but didn't know they had to write a finaliser then that would cause problems if client code did not call Dispose. The GC wouldn't call Dispose and the dev hadn't coded a finaliser so we would have problems. I think this was the scenario I was imagining.
Thanks. I didn't get the idea about keeping dispose pattern in base class just for a case when somebody derives from that class and uses unmanaged code in a derived class. Why not to create a dispose pattern in the derived class? I believe the derived class can implement IDisposable interface too.
The problem is that unless Dispose() is declared as virtual in the base, it would have to be declared new in the derived, and therefore wouldn't be accessible through a base class reference. If you do make it virtual in the base class, then you run the risk that the override in the derived class could fail to call the base class Dispose - thus a mistake in the derived class could cause a resource leak in the base class. Using the Dispose pattern means a mistake in the derived glass will cause leaks only in the derived class.
I've previously read that as well as unmanaged resources, the other way to end up with memory leaks through not using Dispose is by not "unhooking" event handlers and delegates (apparently leaving rooted references to otherwise out of scope objects). Is that correct, or does GC take care of that?
Hi, at 14:00, you are saying that, we don't need to Dispose writerStream in finalizer because it is already a managed object and gc handles it. If GC can handle it without we calling dispose method, why do we really need dispose?? Then we even don't need using statment and dispose because GC can handle it own by own according to 14:00. Can you explain this?
The reason we have Dispose and using statements is so that we can release resources as early as possible. All the GC will do is guarantee that objects will have their active finalizers called eventually. Ideally, _writer.Dispose will have been called long before we reach garbage collection, but if we are in garbage collection, there is no point doing it for ourselves, since either it was done long ago, or it is being done automatically right now.
