If you notice that the Microsoft Foundation diagnostic memory allocator is reporting leaks for non-CObject memory blocks, check your exception-processing logic to see if CString objects are being cleaned up properly.
The CString class is typical in that its constructor and member functions allocate memory that must be freed by the destructor. CString is unique, however, in that instances are often allocated on the frame rather than on the heap. When a frame-allocated CString object goes out of scope, its destructor is called “invisibly” without need for a delete statement.
Whether you explicitly destroy an object or not, you must be sure that the destructor call isn't bypassed by uncaught exceptions. For frame-allocated (and heap-allocated) CString objects, use a CATCH statement to channel execution through the end of the function that contains the CString allocation.
This is an example of incorrect programming.
void TestFunction1()
{
CString s1 = "test";
OtherFunction(); // OtherFunction may raise an exception
// This point not passed if an exception occurred.
// s1's destructor called here (frees character storage for
"test")
}
You must add TRY/CATCH code to free the string character data in response to memory exceptions.
Now the program has been improved to properly handle exceptions.
void TestFunction2()
{
CString s1;
TRY
{
s1 = "test";
OtherFunction(); // OtherFunction may raise an exception
}
CATCH( CException, e )
{
s1.Empty(); // Frees up associated data
}
}