Dispose pattern: How do I know what's managed and what's unmanaged?

views:

379

answers:

+3 Q:

Dispose pattern: How do I know what's managed and what's unmanaged?

Reading about the Dispose pattern, I see the documentation repeatedly refer to "cleaning up managed and unmanaged code". And in the canonical implementation of the Dispose method, I see specific flows (depending on whether disposing is true or false) dedicated to the cleanup of managed objects versus unmanaged objects.

But am I, the lowly newbie, to know which types are managed and which are unmanaged?

If you don't know, the types you're using are probably managed.

Unmanaged types refer to types that are not safe, i.e. not conforming to the CLR safety requirements.

Great definition linked:

Update

I don't understand the downvote? The question was specifically how to differentiate between managed and unmanaged types?

All of the other answers were addressing the IDispose question, rather than the managed/unmanaged question!?

Update 2

Still no explanation of the second downvote...

I agree, an IDisposable object should always be disposed, but that doesn't answer the question about managed vs. unmanaged.

John Weldon 2009-07-10 21:12:07

Similar to my other comment, how do you *know* that a type, as you say, doesn't conform to the CLR safety requirements? I.e. if I were to write a Reflector plugin to report the "unmanagedness" of a selected type, what would my plugin inspect on that type to make a definitive judgement?

Jeff Stewart 2009-07-13 22:32:01

I'd simply suggest destroying all resources after you use them. Anything that usually depends on a system resource such as sockets and stream resources you want to explicitly release. When in doubt go ahead and dispose. Saves you a lot of debugging trouble in the long term. Usually when you call code that isn't written in .NET you can assume it's not "managed code."

Achilles 2009-07-10 21:12:27

+3 A:

The short version is: anything that also implements IDisposable needs to be called in your Dispose method. FxCop will also tell you if you're missing something (or not using IDisposable at all when you should be).

Matthew Scharley 2009-07-10 21:12:47

Though this really doesn't answer the question, I'm no longer convinced that a good answer exists. This provides the best practical solution to the problems that arise when a programmer can't make a judgement regarding a type's "managedness", but I think a programmer who wants a definitive heuristic for making that judgement is just plain out of luck.

Jeff Stewart 2009-08-11 21:32:04

+2 A:

Managed or unmanaged doesn't really matter. If a class implements the IDisposable interface, you should be calling Dispose() when you're done with the object. Alternatively (preferably) make use of the using statement to have Dispose() called automatically when the object falls out of scope.

@ Rob:
The answer is still the same. If your class manages any internal objects that implement IDisposable, it should be implementing IDisposable as well. In your Dispose() method, call Dispose on those objects.

Thorarin 2009-07-10 21:13:49

I think the question was asking from the perspective of designing IDisposables - i.e. what should and shouldn't be freed up when disposing vs. finalizing.

Rob 2009-07-10 21:29:35

@Thorarin - I think the point Rob is making is that if you implement the classic dispose pattern, you have an isDisposing flag to indicate if it is disposing due to a call to dispose, or due to the finaliser executing. In the latter case you would need to be careful not to dispose other managed objects as they may already have been garbage collected. On when explicitly called from a Dispose() method is it safe to dispose these. The *unmanaged* resource should, however, be disposed in both cases.

Rob Levine 2009-07-10 21:55:35

I tend towards the Gestapo approach on that one: if the finalizer is called at all, complain loudly to the programmer to fix their code.

Thorarin 2009-07-10 22:01:08

+5 A:

Unmanaged means native Win32 objects, chiefly handles; and references to raw COM objects. These are resources that are not under the control of (or managed by) the .NET CLR.

John Saunders 2009-07-10 21:15:55

Right, but how would a strictly-.NET developer too young to have used Win32, COM, etc. *know* that a resource is not under the control of the CLR, or worse yet, *depends* on a resource that isn't under the control of the CLR?I mean, how do you *know* that, say, a handle is unmanaged? Probably experience. But in the absence of that experience, how is a greener programmer to get it right every time?I contend that the presence of, say, the IDisposable interface isn't enough; your average programmer isn't taught to check every type's documentation for a mention of IDisposable.

Jeff Stewart 2009-07-13 22:29:22

I say the opposite. If IDisposable is there, then dispose. Period. That way, the tender youth need never be exposed the the trauma of COM.

John Saunders 2009-07-13 22:32:07

ansaurus

tags:

views:

answers:

Dispose pattern: How do I know what's managed and what's unmanaged?

related questions