Memory Management Issues, Solutions, and Examples

Issues in memory management General Issues –Which should manage memory? Library Vs. application using the library Programming Issues –Dangling pointers –Memory Leaks

Which manages memory?

Rule of thumb: If a class manages memory allocation, it should also handle memory deallocation (letting a class allocate space for its data member and another free the space is error prone)

Programming issues Once the decision on where (library or application) the memory is to be manage is decide, there are two programming issues: Dangling pointers Memory leaks

Dangling pointers Cause: Variable is pointing to a memory space that has been freed. Consequence: Programmer refers to variable thinking it points to valid memory location  Segmentation fault. When: Library does not manage memory properly, and application ends up with dangling pointers.

Class X { // constructor and // destructor of X // not needed int X::f(LibClass a) { return a.get_int(); } Example with dangling pointer Class LibClass { int *p; pulbic: LibClass::LibClass(int i) { p = new (int *); p = i; } LibClass::~LibClass(){ delete p; } int LibClass::get_int(){ return *p; } void LibClass::set_int(int i){ *p = i; } void main () { int i=1; LibClass b(i); X c; c.f(b); b.set_int(2); } Implicit call to copy constructor Destructor called to destroyed copy created by copy constructor Space for p data member of b has been destroyed  Dangling pointer

Solution to dangling pointers Need to introduce an copy constructor LibClass::LibClass( &LibClass ) Options: –Copy constructor creates its own space and then copy the values. –Copy constructor increment counter, destructor decrement counter and destructor free memory when counter = 0.

Questions How should the example be modified to implement each option of the solution? What are the pros and cons of each option?

Memory Leaks Cause: At one point of execution, no variables point to a memory space allocated by the program. Consequence: memory memory gets full and space cannot by allocated When: Neither library nor application frees memory

Example of memory leak Class LibClass { int *p; pulbic: LibClass::LibClass(int *i) { p = new (int *); p = i; } LibClass::~LibClass() { } int LibClass::get_int() { return *p; } void LibClass::set_int(int i){ *p = i; } void main () { int i = 1; int j = 2; LibClass b(i); LibClass c(j); c = b; } Destructor does not free memory Implict call to operator=(&LibClass) Problem of memory leak: After assignment ‘c = b’, the space to which b.p was pointing has not been freed, and no variables point to it.

Solution to memory leaks Need to introduce an explicit = operator LibClass::operator= ( &LibClass ) Options: –the = operator creates its own space and copy values into space and the destructor frees space (problem: keep consistency between copies) –the = operator increment a counter and destructor decrements counter and frees space when counter = 0

Questions How should the example be modified to implement each option of the solution? What are the pros and cons of each option? If ‘main’ was to handle memory management, how would you modify the implementation?