Super Bed-Wetting Leaks

[savage]

Hi, I want to ask a big question about leaks, and all kinds of leaks.  Memory/resource/handle/DC/underwear, you name it.  This is the question for them all.

When you run a program, you create all kinds of these things, but which ones are not destroyed automatically when the program closes?

I always see programs do clean up code on the WM_DESTROY message of the main window, but is this really necessary? Can anyone tell me which ones are impossible to leak and which ones are always leaked?  I know memory can't be leaked out of a program, (or can certain types be?) but can anything?

This is a question I'm sure many others would like to know too, so if anyone knows the facts behind it, thanks.

[stanhebben]

I don't know of any leaks that aren't handled upon application exit.

Collecting your garbage when your program exits isn't necessary, but it's good application design.

The main reason why I collect my garbage at the end of the program is to remind myself that those things take up space. Then, when my program becomes bigger, I may want to move the cleanup code to another place (to free up memory, or eventually for other reasons).

My opinion: if you make a small program for a simple task, don't care about it. If you want to make a bigger project, clean up everything.

Stan

[arafel]

I don't know of any leaks that aren't handled upon application exit.

CreateMenu for example.

The system does not automatically destroy a menu that is not assigned to a window. An application must destroy the unassigned menu by calling the DestroyMenu function.

There are some other stuff that may leak if not properly freed before application exit.


Windows garbage collector should be considered only as prophylactic measure, it's up to programmer to take care of the allocated resources.

[Mark Jones]

Try running your code through MemProof, that can show you which resources are not freed and even which ones change (such as a MemAlloc growing.) Google it.

And of course freeing a few icons is a different type of "memory leak" than a faulty algorithm which consumes large chunks of memory during repeated loops. :bg