And following on from that (isn't this fun?) is the distinction between the heap and the stack. The stack is memory you allocate like:

Code:
void myFunction ( void )
{
****int myInteger = 0; /* INT memory allocated. */
****/* Some other stuff. */
}
myInteger ceases to exist when the variable goes out of scope - basically when the function ends and the function itself goes off the stack. The memory is freed up and you don't have to do anything else. This is all very nice, pragmatic and no end of use but has problems like we've mentioned.

So you might need to dynamically allocate memory like this:

Code:
void myFunction ( void )
{
****int* myNiceInteger = new int;
}
But now you've opened a whole new can of worms. The trade off is you get your dynamically allocated memory, but now you have to be very careful what you do with it because it's on the heap instead of the stack.

It's easy to forget to delete the int, and as you're using up memory that the OS doesn't know when to free up (because you explicitly put it on the 'heap' instead of the nicely ordered 'stack' it's not going to touch it) it's used until the program ends. A few thousand calls to that function - you can imagine it being a new class or something much more memory intensive instead of a humble int - and you very quickly have a problem. One that can be hard to find.

But you do need a pointer to allocate memory like that else you won't be able to find it, and you do often have to allocate memory on the heap. If you lose the pointer, you're also going to have trouble finding that variable again and deleting it. That is to say, it will be impossible. There's also problems with causing what Windows 98 charmingly called a general protection fault: buffer overruns, accessing memory that isn't yours by mistake and the popular "causing your program to go up in flames in front of your boss". It's not something a compiler is able to catch either, and the only obvious effect is when your program quietly corrupts itself or crashes.

Nice, isn't it?

So if you don't delete (italicised because it's the C++ keyword) that memory you will get the good old fashioned memory leak. The memory will just sit there whiling away RAM until the program ends and the OS can then (and only then) be confident in cleaning up in the heap without upsetting whatever your program is doing. Memory leaks and the management of dynamically allocated memory - or lack of it - is one reason that people do not like C++ as much as they otherwise might. Hence Java and C# having what's known as garbage collection to tackle this problem and make your life that much easier. Me, I like the sense of adventure that a lack of guard bytes and so on can bring.

I'm not entirely sure who I'm explaining this to, either, but it's fun.