How IDisposable, Dispose, and Finalizers work in C#
ฝัง
- เผยแพร่เมื่อ 2 ม.ค. 2025
- In this video I will do my best to help you fully understand the IDisposable interface, the basic dispose pattern, finalizers, and how your implementations of Dispose interact with the GC and garbage collection when dealing with managed and unmanaged memory.
Source code:
1drv.ms/u/s!Ag...
Slides:
1drv.ms/p/s!Ag...
#dotnet #csharp #dcomengineering
Best explanation of why/when and how to implement IDisposable pattern I've seen ever! Thank you!
Finally a concret implementation for IDisposable pattern.
Thank you very much !
I am literally thrilled with your way of explanation, thanks for the excellent work.
Thanks! GC is a tough topic!
Great video that helped me to freshen up my knowledge about some specifics.
Thank you for the great explanation. I look forward to see your new videos. ❤
Well, that's a great video. Thanks for the clear explanation!
Thanks a lot for making such a great video. Its really informative and helpful!
Glad I could help!
Thank you for a very good and clear explanation of the IDisposable interface. I have one question though. At 30:46 you are mentioning the call to image.Dispose() as a managed resource. Isn't image here an unmanaged resource that you are disposing? I know you are correct in what you are saying, since the Microsoft documentation is saying the same thing, but I really can't get why it is called 'managed'. I'm very new to C# (coming from Java) so maybe it is obvious to everyone else? :)
The Bitmap object itself is a managed object - in that it is a class with properties, methods, and private fields. Those take up managed memory when you create the object with the new keyword, so you have storage space required for the object itself, as well as the underlying unmanaged bitmap (the pixel data, basically). The unmanaged memory, if you were to decompile the Bitmap object or look at the source code, is probably accessed by a pointer. The GC knows how to free up the memory the class itself used, but not the underlying pixel data that is unmanaged. If you think about it, the difference between "managed" and "unmanaged" memory could simply be referring to memory that is either managed by the GC, or not managed by the GC. Often times when dealing with IDisposable, you have a hierarchy of managed objects that implement the interface and dispose of one another, and the inner most wrapped object (Image in this case) would be the one actually containing the unmanaged memory (pointer or some other method)
great video! saved to my playlist
Hello, thank you for your presentation, made things clear and simple !
I'm not expert in C# so sorry if I missed something, but I just have one issue I'm a bit confused with : in your example with the derived class, a call to "image.Dispose()" is in the "Dispose" which overrides the one of the base class, however, the Dispose() in the base call already calls "image.Dispose()". I might be wrong but it is as if we attempt to dispose of the same resource twice, because the Dispose of the base class gets called at the end if the overriding Dispose ?
I read the Dispose mechanism is taking care of the call redundancy doing nothing at the second call, but since the image is defined in the base class primarily, does it suffice to have the Dispose of the base class calling the Dispose of the image, and have nothing to dispose in the derived one ?
If so, might I suggest you enhance the example with another image in the derived class (such as "alternateImage" maybe, for example), which I guess would be the sole resource to be freed in the derived Dispose ? It would be interesting because I found even in Microsoft documentation such example is lacking.
Thanks !
Great explanation
Glad it was helpful!
Things to consider for your next presentation: Show your presentation in full screen. Show your code in full screen without windows on all sizes reducing the relevant space to a minimum. And don't use a semi transparent console which just distracts again from the relevant content. That said, well explained and very informative!
Like!!!
Coming from C++, I think .Net GC should also be considered a memory leak. 🤣
I understand your point of view. I did not spend a lot of time in C++, but ensuring the code deletes objects from memory immediately instead of (not, as many developers don't), or deferring it to the GC to run at some indeterminate time can be a strange leap. I haven't seen a lot of C++ source code in real applications, but even with .NET GC developers don't call IDisposable.Dispose (they rarely check if a class even implements it). Even though the GC provides automatic reference counting memory management, developers should still have the C++ mentality of deleting objects from memory (or in this case, calling Dispose)
One of the worst videos on Dispose and finalize..if you are a educator explain in a way everyone understands, not just some selected people!
You might be missing foundational knowledge that would allow you to consume this video adequately. This wasn't entirely a beginner video, I would say.