Tuesday, March 16, 2010

A Reallife Story about Memory Leak

My colleague alerted me today a potential memory leak in a component that I have written. It looks like the following piece of code:
try
{
    // new an object.
    // Call the Init() of the object, that may throw in case of error.
    // Put the object pointer into the pool.
}
CATCH...

I use capital CATCH here because actually, I used a macro that wraps the standard catch into one line. While it simplifies the code, it also made me to forget to do necessary cleanups in the catch clause. Finnaly, I gave up using the beautiful macro and went back to the standard catch and put a delete there.

More words on the pointer in the pool. It seems that to put the object itself in the pool is better but this is possible only when the class provides a default constructor and a copy constructor, if one uses a STL container as the pool. It is not my case, the class I'm using does not have a default constructor nor a copy constructor... Bad design or are there some special reasons to not provide a default or copy constructor?

No comments: