I’d wager the majority of programmers alive today have never once worried about malloc(). - And you’d be very, very wrong. Anyone who has ever used C, C++ or relatives, or has written an interface to a C library from a higher-level language, has dealt with explicit memory allocation.
It would be very depressing to find that that doesn’t constitute the majority of programmers…
Hopefully someone with more knowledge than Jeff and more time than myself will explain why it is better to explicitly dispose certain resources rather than leaving it up to the GC.
@JG: It’s probably an implementation-dependent things, but in a lot of high-level languages you can indeed force a GC immediately.
sqlConnection.Close();
sqlConnection.Dispose();
sqlConnection = null;
You forgot to put this in a try / finally block.
There are a lot more programmers that have written C than you think, not everyone comes from a Visual Basic application writing background.
You’ve given us yet another implicit example of why learning C is really a necessity for becoming a well rounded programmer.
Just recently, I saw this in an application I was working on:
try
{
cmm.ExecuteNonQuery();
}
catch (Exception ex)
{
conn.Close();
conn.Dispose();
Application.Exit();
return;
}
The garbage collector will cruise by periodically, and when he sees stuff you’re not using any more, he’ll clean up behind you and deal with all that nasty pointer and memory allocation stuff on your behalf. It’s totally automatic.
The garbage collector is male?! How come it’s not female? 
From MSDN:
GC.Collect()
Forces garbage collection of all generations.
This is a .Net Framework call - C#, VB.Net, etc…
And on rare occasions I’ve had to use it.
I used malloc once or twice…but what about c++'s new and delete? That’s what I remember the most from my early days of programming.
In C# the easy way is
using(var sqlConnection=Connect()) {
… use the connection …
}
this causes Dispose to be called on the connection when you leave the block: doesn’t matter if you fall out the bottom, leave via return or continue or throw.
My own preference is to use Nuke. Shorter but just as passionate. And have you ever noticed that no one deletes a folder? They blow it away. Too many hours playing Doom I suppose.
but what about c++'s new and delete?
C++ has had deterministic allocation and disposal of memory and other resources via autoptr for years, I don’t think I used explicit allocation for most of my 96-2003 C++ career.
Though the modern-day Garbage Collectors claim to be smart and efficient, their non-deterministic behavior pisses me off.
After all, in JAVA, gc() is a mere suggestion to the JVM 
I still love my free(x) and delete x;
I’d wager the majority of programmers alive today have never once worried about malloc()
Oh… I’d better check if my ~35 yo friends are still around, then.
You must have a pretty low life expectancy in the US 
I beg to differ on some of your points.
using (var c = new Disposable())
{
c.DoSomething();
}
c = null;
DoSomethingElse();
Disposing c will release any unmanaged resources it will use, but not all managed resources. The class itself takes some memory and it may contain references to other classes. Maybe c contains a reference to several Gb of XML. By setting it to null this allows it to be garbage collected before DoSomethingElse is called, which could make an enormous difference. The CLR should perform liveness analysis on c and eliminate the need to set it to null, but if this was a field then it can’t do this.
This is wrong. Take IEnumeratorT. This derives from IDisposable. Just because something can be enumerated over does not mean that enumerating it will require unmanaged resources!
Now come on Jeff I have just had to read through all the posts, to confirm you don’t need sqlConnection = null;. Seems so, hopefully correct as I have never used that line.
Associated with this topic is that people should be reminded that they technically should still call the ‘close’ function on an object (as well as dispose)… technically the disposable contract doesn’t state anything regarding ensuring closing of the object… whilst most dispose methods do, they are specified not to throw an exception if the object is already closed / disposed…
so you should always do
using(var disposable = … create disposable …)
{
… do your thing …
disposable.Close(); // – Or whatever the ‘close’ method of the type is.
}
For me explicit disposal is probably most important when working on file streams.
A long time ago, malloc() used to return char *, so casting was necessary. In 1989 the void * pointer type was introduced in ANSI C, and since then, malloc() returns void *.
So don’t forget to include stdlib.h and then it doesn’t matter if you cast the return of malloc() or not.
But if you do cast it, be aware that it will probably prevent the compiler from warning you assignment from incompatible pointer type, as it will assume that you know what you are doing.
Thus, the recommended usage is generally:
#include stdlib.h
double *b1;
b1 = malloc(m * sizeof(double));
This is even better, as you don’t have to worry if the type of the pointer changes:
#include stdlib.h
double *b1;
b1 = malloc(m * sizeof *b1);
Note that casting the return of malloc() is required in C++ however.
What’s that sound I hear? Is it the sound of Comp Sci grads who learned C/C++ in school gathering their pitchforks and torches?
@Oliver: In your example (which won’t even compile) the variable C goes out of scope when the using block ends, freeing itself for garbage collection.