Re: What does it mean to set large fields to null
- From: "Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx>
- Date: Thu, 18 Jun 2009 16:01:10 -0700
On Thu, 18 Jun 2009 15:32:40 -0700, Andrew Falanga <af300wsm@xxxxxxxxx> wrote:
Hi,
I'm going through a link provided to me from someone here earlier
about implementing the IDisposable interface on factory patterned
objects. In the document from MSDN I'm seeing this comment in the
Dispose( ) function:
// Set large fields to null.
Is this something as simple as this (an example):
byte[] byteArray = new byte[/*some really large number*/];
byteArray = null;
I believe that's what they're talking about.
But, that doesn't mean it's really a good idea in general.
[...]
Since implementing IDisposable I'd like to know about how I can grab
enough memory to load the graphic data into memory, similar to a
Bitmap object, and then, like the Bitmap, call Dispose( ) on my object
and watch the memory drop. From my C++ experience I would do this by
freeing a pointer. However, I don't know how to hold onto a valid
pointer reference outside of unsafe code, and I'd need to for this to
work. So, how do I allocate enough memory to hold the graphic data in
memory and then release with a call to Dispose( ) when I want to?
Why do you want to? Can you be more specific about what you're actually doing? Actual code would be best.
IMHO, IDisposable is really about dealing with unmanaged resources. It works hand-in-hand with the finalizer to provide client code with a well-defined API for ensuring that resources .NET has no way to explicitly manage are still released in a timely way when the client code is done with them, and a back-up system in case the client code has a bug and fails to release those resources explicitly.
Even if you did have a data structure that could potentially allocate a large amount of memory and then later have a sensible use case where you would want to release that memory without releasing the entire data structure at all, I don't really feel that IDisposable is the right way to go about it. I agree with the design found, for example, in the List<T> class where there's an explicit method specific to the type to accomplish that (i.e. the "TrimExcess()" method).
And in most cases, that large internal data structure only becomes useless at the same time that the data structure itself becomes useless, in which case you should not be trying to manage it at all. It will be garbage-collected along with the containing data structure when the proper time comes, and there's no reason to burden the client code with additional work to try to manage that.
Pete
.
- References:
- What does it mean to set large fields to null
- From: Andrew Falanga
- What does it mean to set large fields to null
- Prev by Date: Re: MemoryAccessViolationException and multimedia timer problem
- Next by Date: Re: Sorting Array using Icomparable
- Previous by thread: What does it mean to set large fields to null
- Next by thread: Re: What does it mean to set large fields to null
- Index(es):
Relevant Pages
|
