View Single Post
Old Aug 19th, 2005, 7:09 AM   #18
DaWei
Resident Grouch
 
DaWei's Avatar
 
Join Date: Jun 2005
Posts: 6,453
Rep Power: 10 DaWei is on a distinguished road
Simplification: Memory leaks come about when a program requests additional memory from the system at run time. This comes from the heap or free-store. If the request is granted you get a pointer to that area and use it. When you've finished with it you return it, using the same pointer (or a copy) to indicate what you're returning. If you fail in that, the memory remains unallocated and is unavailable for further use. Some allocations may be recovered by the system under certain conditions, at certain times, even if you fail to handle it properly. At the extreme, for example, it is ALL recovered when you reboot. You have no overt allocation showing in the code. There's not much telling what the DB operations do under the covers.

I can read your program, of course, though I'd make plenty of syntactical errors and trips to the reference material if I were writing it. It seems straightforward enough.

If you don't find the employee in the inner loop, you do a MovePrior and check the preceding record. If you DO find the employee, but you don't clock 'im out and set Executed to true, you DON'T do a MovePrior, so you're locked up there.

If MoveNexts or MovePriors or EOFs or BOFs aren't working properly or invoked, you won't exit the loops.

Do you not have a debugger so that you can step through?
__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers
DaWei is offline   Reply With Quote