Effective C#: Implement the Standard Dispose Pattern

It is broken because not only do I, the implementer of an object, have to implement Dispose() when my object uses an unmanaged resource, but you, the client using my object, must remember to call Dispose() on it (or use a “using” statement for my particular object).

This is totally false if you were a good developer you do the following (don’t fault the good developers for the few bad ones out there):

<pre>

class MyClass : IDisposable {

public MyClass () { /* consturctor */ }

public void Dispose() {

Dispose(true);

GC.SuppressFinalize(this); // very important

}

protected void Dispose(bool b) {

if (b)

// clean managed code here

// clean unmanaged code here

}

~MyClass () {

Dispose(false);

}

}

</pre>

I hope this was educational for all of you out there that says you can’t control how and when the code gets removed. Not only can I clean up on my schedule, but if I don’t clean it up the GC will clean up the unmanaged code for me.

Ignorance is no excuse to rag on something you don’t understand. It’s even more ingorant to say you understand the language when you are missing something as simple as the code I just introduced above.

is in that he doesn’t even realize that C++ is only a quasi-object-oriented language, in addition to Java. .Net on the other hand corrected the problem of using primitives, so it is truely object-oriented

OO is not the end all, be all programming paradigm.

And give me a definition of OO that a majority of people agree upon. I don’t think it exists. Various people have different conception of what exactly define OO and what the minimal feature set of a language must be do be deemed OO. Therefore, saying that language X is more object oriented than language Y doesn’t make much sense.

And please define “primitives”.

The C++ for .NET which is currently being worked on will offer a “best of both worlds”: The destructor gets called at a deterministic time, yet memory management is left to the garbage collector.

I am certainly not dissing C# as a welcome alternative for rapid application development, and it’s much nicer than, say, jscript for that purpose.

Also, I’m not suggesting C++ is perfect.

What I take issue with is the hordes of people having coded their Easter Date Calculator in .NET in less time than it took in C++, and hence deride everyone “still” using C++ as being “old-fashioned” and outdated.

That’s why I wrote the article – C# is not my favorite programming language, because it doesn’t fit the kind of work I need to do.

As an example, someone here at our company writes an application in C# on top of a server in C++. There are objects representing (large) images, which are wrappers around shared memory. To the .NET garbage collector, these objects look quite small, so it doesn’t bother cleaning them up. However, virtual memory space was getting exhausted and the application ground to a halt.

The programmer had to resort to manually implementing a Dispose() method which explicitly freed the memory when it was no longer in use (despite the original object being a COM object, which already has reference counting) and calling Dispose() “every once in a while”.

Since the whole concept of garbage collection was “you don’t have to worry about your old objects anymore”, I don’t think this is something this programmer should have to waste his time on. Especially since it would have been avoided if destructors had been called at a deterministic time.

And please define “primitives”.

Primitives is a concept in essence where something that acts like an object to the programmer is interpreted in the compiler and then translated to something the processor understands. Such as an int in a 32-bit processor is different than one in a 16 or 64. Usually primitives are numbers, and other processor speicific “devices”. (I use devices loosely, because I am not sure if all languages have just numbers as primitives, all the ones that I have run into do though).

However the “primitives” (or a better name for them is aliases) in .net ARE objects, and care with them everything that an object normally would, (i.e. methods, properites, events, whatever).

I also ment to offense, which is why I used quasi-obeject-oriented, which is an excepted term amoung accademics, at least when I was in school, for how to define C++ and Java. This was done, because the building blocks for all the rest of the classes in a package, namespace, or whatever are build off of the primitives, which are not objects. That is why makes C++, and Java Qausi-Object-Oriented.

you guys are finally getting it

Sigh. I spend several postings here trying to explain how currently, C# does not have deterministic destructor behaviour, and why that is bad, and getting posts in return stating that this is not a problem at all and that “this guy really doesn’t understand it”, and what I say is “totally false”. Then I point out that even the .NET-people recognize it, and how suddenly “we” are finally getting it?

Oh well. Since I refuse to get with the time and am still stuck using an outdated programming language, I have some more work to do while you guys can already go home, so I’d better get to it. Cheers!

Don’t forget about the Boost smart pointers! You really don’t have to implement them yourselves all that often anymore. Other than that, you’re dead on.

I spend several postings here trying to explain how currently, C# does not have deterministic destructor behaviour, and why that is bad, and getting posts in return stating that this is not a problem at all and that “this guy really doesn’t understand it”, and what I say is “totally false”.

All I can say is your absolutely correct. Anybody arguing against this point hasn’t been reading MSDN lately — and obviiously haven’t been reading on the advantages of using C++/CLI. Since there’s information aplenty on MSDN, I won’t repeat what’s written there….if you doubt what Sander has been saying, go do some homework.

I wasn’t saying in C# they are called primitives. In Java, and I have heard it many ways for C and C++, they are called primitives. In C# the best term is alias.

It’s held as true, in most academic class rooms (people that actually care about this stuff), but because C++ uses primitives, (value types or whatever you want to call them). It is not truely object oriented until you can do:

int.SomeStaticMethod()

— or —

int i = 0;

if (i is Int32)

Console.Write(i.ToString());

That is what I mean by totally object oriented. If a part of the language isn’t object oriented but treated like it is just for the sake of the programmer than the language isn’t totally object-oriented.

For a language to be object-oriented you need “EVERYTHING” to be an object, not just some parts of it. That is what I was talking about. The word “primitive” comes from types that aren’t objects and are at the basis when you get down to the nitty gritty after go through all the levels of inheritance.

Basically everything in C++ all boils down to using “primitives”, much like all of math eventually boils down to addition.

“The programmer had to resort to manually implementing a Dispose() method which explicitly freed the memory when it was no longer in use (despite the original object being a COM object, which already has reference counting) and calling Dispose() every once in a while”.

Then the programmer still did it the wrong way. Have a look at System.Runtime.InteropServices.Marshal.ReleaseComObject(), there is an excellent blog about using this method here: http://blogs.msdn.com/cbrumme/archive/2003/04/16/51355.aspx.

It’s a good idea NOT to get overzealous with implementing the Dispose pattern; you only need to use this if you need deterministic finalization, which for 90% of the scenarios out there is simply not needed. If you need more agressive GC’ing, use the ServerGC, not the client (google mscorsvr.dll mscorwks.dll for more information concerning the differences between the 2 GC’s, it should be worth noting that the two have merged in 2.0 and mscorsvr.dll appears to GC engine). Cheers.

Hi. I just noticed your moderated-down link (which is IMHO at least partly on-topic…).

You hit the nail on the head. What you write is *part* of what I think is wrong with Java, and OOP in general, as it is used!

Too bad the rest of your website is all in Dutch

I think it’s hard to change an interface to a class without breaking all code (in a single-inheritance language).

Also, inheritance in general is a bad/dangerous thing (fortunately more and more people adopt this opinion). Even James Gosling (the main Java designer) said, that if he would design Java today he would leave out classes (and keep interfaces).

As IDispose indicates merely that a class complains to the Dispose protocol, I think the name is not too bad.

BTW. I did a quick google on Hungarian Notation. What’s so bad about it? It seems to be the notation that most non-C libraries use (Java certainly), and I find o.addVal(v) better than o.add_val(v), for that matter (partly because the _ is awkward to type…).

BTW. I did a quick google on Hungarian Notation. What’s so bad about it? It seems to be the notation that most non-C libraries use (Java certainly), and I find o.addVal(v) better than o.add_val(v), for that matter (partly because the _ is awkward to type…).

This is not Hungarian Notation. Hungarian Notation means you prepend variable names by a moniker depending on their type, so you’d have int iIndex, double dValue, etc. all the way up to LPZWRSTR or whatever it’s called.

This is bad, because the name of the object should say something about what it represents, not how it represents it.

Try writing image processing applications (which I do)

We’re looking to hire another Image Processing Guy. Care to move to The Netherlands? The weather sucks, but coffee’s free here at work.

But don’t blame the language for a lack of understanding of garbage collection.

I assume you meant my lack of understanding, but your sentence can also be parsed like this: “Don’t blame the language because it lacks understanding of garbage collection.” And this is exactly what I want to do. If a language provides a garbage collector, it should damn well understand garbage collection. So far, nobody here has pointed out that there are other resources beside just memory, and the garbage collector currently in .NET doesn’t cope well with that.

Everyone keeps bringing up that this is “marginal use case”. Exactly! I, the implementer of an object, know that I’m using precious resources which shoud be released ASAP. The only way I can “enforce” this in .NET is by printing in big red letters on the box I’m selling my component in, that its users are supposed to call Dispose() “every once in a while”. Programmers will forget this, because they’re told that they “almost never” need to worry about disposing of resources themselves.

Had C# offered deterministic destructors, this problem would have been easily overcome by me, implementer of the object, by giving it a destructor and calling Dispose() from it.

I’ll stop wasting my time on the subject until someone can give me an example of why it would be better to have indeterministic destruction (random generators are explicitly excluded!).

Memory Management is tedious, if:

(1) you use a library (like malloc in C) instead of some nicer syntax, like new in C++ for instance

(2) the programmer has no concept of his program at all (its structure) and just allocates/decallocates resources all over the place. Since you have to manage non-mem resources anyway, I see no reason not to just do all cons/destruction explicitly.

Note that I’m not really a C++ guy, and C is pretty low-level for most things, but in principle I’m doing well with manual MM (would be nice to see a decent high-level language with explicit resource management; maybe I should build one some time…)