Do I always have to Close handles like hFile?
What if I put a new Filehandle in hFile? Is the previous handle closed before? Are all handles closed when my Prog quits?
Posted on 2002-08-11 08:16:30 by Subby

Make it a rule, ALWAYS close the file handles that you open, otherwise you leave a file open after your app closes.


Posted on 2002-08-11 08:30:47 by hutch--
Hey Subby,

Yes, As soon as you are done with the file, you should call CloseHandle.
No, overwriting hFile will not close the handle. It just means that you've lost the handle value and can kiss any chances of closing the handle goodbye
No, I believe that closing your program does not close handles.

If you don't close handles you will get memory leaks and other programmers will frown at you and make faces. In the case of files and similar, failing to close a handle could result in another application being unable to access the file (ex. if you call CreateFile without FILE_SHARE_xxx)

Posted on 2002-08-11 08:35:03 by chorus

But for example these handles:
etc are closed automatically when the prog quits, arn't they?

Is there any rule which handels to close manually like hFile?
Posted on 2002-08-11 08:37:31 by Subby
Oh... you mean like *all* handles...

Let's see,
Windows: shouldn't have to worry about these. They will be closed by DefWindowProc when WM_DESTROY is sent to any and all windows
GDI Objects (brushes, fonts, pens, etc): You are responsible for closing these handles by calling DeleteObject
Device Contexts: Each call to GetDC should be matched with a ReleaseDC (unless your class has CS_OWNDC)
Files: your responsibility to be closed with CloseHandle
Memory Blocks: your responsibility
Resources (icons, menus, etc): Depends on if you use Loadxxx or Createxxx. You'll have to check the APIs for these

I think that's mostly it.

Posted on 2002-08-11 09:40:42 by chorus
For example
Iczelion's Tut #5.

He didn't close the hFont.
Little mistake, or wasn't it necessary?
Posted on 2002-08-11 09:49:53 by Subby
Good eye, Subby. You're right, there should be a DeleteObject following the SelectObject which restores the original font. Especially since he's creating a font every time WM_PAINT is called. I would suspect major memory leaks, and eventually, the CreateFont would probably fail.

In an instance like this I would recommend creating the font in say WM_CREATE and saving hFont in a global. Every time WM_PAINT is called, use SelectObject,ps.hdc,hFont to move the font in and restore the old font. In WM_DESTROY, add a DeleteObject,hFont to clean up the created font.

This'll mean less work in WM_PAINT, and also means hFont is reusable. For instance, I find I like to use a custom font in several windows so I don't recreate the same font a bunch of times.

Posted on 2002-08-11 10:30:43 by chorus
I thought exitprocess closes all open handles.
Posted on 2002-08-11 15:32:30 by eet_1024
A lot of stuff is freed on ExitProcess:

Terminating a process causes the following:

All of the object handles opened by the process are closed.
All of the threads in the process terminate their execution.
The state of the process object becomes signaled, satisfying any threads that had been waiting for the process to terminate.
The states of all threads of the process become signaled, satisfying any threads that had been waiting for the threads to terminate.
The termination status of the process changes from STILL_ACTIVE to the exit value of the process.

However, it's good practice to close file handles when you're done with them, do memory cleanup, etc... and you *must* do GDI cleanup, that is *extremely* important... put a smallish GDI leak in a loop, presto, win9x BSOD.
Posted on 2002-08-11 17:07:03 by f0dder

Its nearly the same rule with ANY handle, GDI resources, file handles, menu handles etc .... but one modifying factor is where the handle is allocated. Many things are freed when a window closes so things like child windows and menu handles are automatically freed when the window is destroyed.

GDI resources like brushes, fonts, bitmaps, icons etc .... are not freed automatically in all instances so it is good practice to make sure that you deallocate such resources. Check the return values of the functions that deallocate the resources to make sure you got it right.

It sounds like more work but it will make your software a lot more reliable and you will not get memory leaks when you do it properly.


Posted on 2002-08-11 19:54:02 by hutch--
If you use an item, clean it up !!!
Dont assume anything will be done for you.
Posted on 2002-08-11 22:24:56 by James_Ladd

Its nearly the same rule with ANY handle, GDI resources, file handles, menu handles etc ....

You don't *really* need to close file handles nor free allocated memory... it *is* handled on ExitProcess... but not taking care of these things is sloppy dirty coding.
Posted on 2002-08-12 09:42:39 by f0dder

i make this tiny code:

invoke Sleep,50000
invoke ExitProcess,0

while the program sleep, i can't access "a_file", but why i can access it when the program stop running?does it mean that the system automatically close "a_file" handle?anybody can give me a prove that if i dont close file handle i'll get memory leaks?
Posted on 2002-08-12 16:14:19 by iona
hmm I think this confirms fodders explication
Posted on 2002-08-12 16:18:51 by Subby
You should always tidy up your handles. Will ExitProcess take care of it. Well, the API says so and it is pretty accurate. But regardless you should be cleaning up after yourself.

How many programs last 50 seconds or less? Why would you tie up a resource for the entire time your application is open? Especially since most file operations go Create/Read or Write/Close pretty much consecutively.

Then there are brushes and DCs and other GDI objects which can come in limited supply. The more of these you create and leave unused in the system while your program is running, the more memory you are wasting. You may even be blocking another program from grabbing a DC.

As f0dder said, it's sloppy coding. But you also have to remember that you are working in a multitasking environment with limited (though maybe large) resources.

Memory leaks aren't the only thing you have to worry about.

Finally, don't forget that your program may not get to ExitProcess if the user kills the process or your program gets a GPF.

Posted on 2002-08-12 16:57:47 by chorus
As many have pointed out, cleaning up after yourself is important !

Looking for a way around doing this is just lazy !!

Why do you NOT want to clean up after yourself ?

Posted on 2002-08-12 17:24:20 by James_Ladd
So lets say:
You should clean up, but if you forget to clean up sth. its not that bad.

Posted on 2002-08-12 17:25:27 by Subby
It's not bad in the you'll-get-lung-cancer sense, but it is bad in the lazy-programmer sense.

Now, if you are forgetful and don't delete a brush here or there it won't be a big deal. Windows can catch this. But you shouldn't just let windows clean up after you all the time.

What I do is this: I create two procs called Initialize and CleanUp. Initialize gets called right after I get the module instance. CleanUp gets called right before ExitProcess. I create most brushes, fonts, menus for the lifetime of the app and I put their creation in Initialize. Everytime I put something in Initialize, I put the corresponding destroyer in CleanUp. It's pretty much fool proof.

For handles with a short life, just watch out for them.
Posted on 2002-08-12 17:38:56 by chorus