Memory leaks, the curse of dynamic memory allocation
Next to crashing programs, memory leaks are a nightmare to deal with. If a program runs 24/7, the smallest leak will eventually lead to a program or system crash because the resources are exhausted.
There are different ways to get a memory leak:
- it may be outside your control, because you use a user or system library which has a memory leak;
- it may be because the designer of a class which you use made a mistake;
- it may be because you fail to delete an object or other memory which you allocated.
The result of a failure to delete objects properly is often (only) a memory leak, and often the leak does not show because the program is a short utility, or because not many objects are instantiated. Keep in mind, however, that objects can have other side effects which will not go away when the program terminates, such as temporary files left behind, allocated shared memory, message queues, semaphores, even network sockets to other systems. Do not assume that objects perform only benign operations which are undone when the program ends. Always delete objects which you created.