Quote:>A third party utility is telling me that when I call the CStringArray
>RemoveAll() function the memory is not being freed. The CStringArray
Which version of MFC are you using? Which version of which third-party
tool are you using? Unfortunately, some third-party tools, like
BoundsChecker, frequently produce false alarms. Some of those tools
are put at a disadvantage when they're abused: if you use
BoundsChecker 4.0 against MFC 4.2b, for example, you'll notice all sorts
of bogus reports. The problem is remedied by using matched sets of MFC
Quote:>"When a CString array is deleted, or when its elements are removed,
>string memory is freed as appropriate."
Yep. RemoveAll() calls SetSize(0). SetSize(0) calls the destructors
on all of the elements in the array by calling DeleteElements(),
and then deletes the block of memory used to hold the elements by
calling delete directly.
Quote:>The same situation occurs when my CDocument-derived class which
>contains the CStringArray as a member variable is destroyed. The
>memory is not freed. There are no memory leaks being reported.
That strongly suggests that there really aren't any memory leaks to
report in the first place.
Quote:>I can program around this but does anyone know of the reason for it?
Before you go through the effort of programming around this alleged
problem, I'd strongly encourage you to trace into RemoveAll() and check
for yourself to see that the memory is indeed not being freed. If you
can make a reproducable case where CStringArray::RemoveAll() isn't
freeing everything, send it along to me and I'll see that it's fixed.
But, with MFC 4.21, I can clearly demonstrate that this code:
for (n = 0; n < 100; n++)
str.Format("String number %d", n);
ends up destroying all the memory owned by the CStrings in the array and
then destroys the memory used by the CString objects themselves.
You can see the code for yourself; the guy that does the work is actually
CStringArray::SetSize(), which is on line 90 of the file ARRAY_S.CPP in
the 4.21 version of the libraries. I can't imagine the code moved around
much since MFC 4.0, so it'll probably be near there even in an older
version. Trace into your call to RemoveAll() and watch the memory
being deleted before your eyes!
I think that a little bit of investigation will reveal that your leak
testing tool is actually reporting a false alarm.
MFC Development Lead
It's a sequential twin turbo dual rotor *el. Why?
I don't speak on behalf of Microsoft.