vector = automatic memory leak!??!?!?

Is this a fake memory leak or what? How come a vector trips the _CrtDumpMemoryLeaks() into saying there is a memory leak???

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#include <iostream>
#include <vector>
#include <crtdbg.h> 
using namespace std;

int main()
{
	vector<char> vFile;

	vFile.push_back('a');
	vFile.clear();
	
	cout << _CrtDumpMemoryLeaks();
	
	system("pause");
return 0;
}
Because clear() does not actually free all of the underlying memory of the vector.
its not neccessary that what every memory debugger says is correct..
for example.. memory allocated in one class which is freed in some other class is a memory leak for them or a potential memory leak.. so dont worry.
I'm following up jsmith's comment by saying that after the call to clear the vector would return a size of 0. However, the vector does not release its internal memory so that if you insert a new value later that existing memory will be reused. When the main function exits the vector object (which was allocated on the stack) will release its memory in its destructor. In this program there is no memory leak. you are dumping the memory leak info prior to destroying the vector. Try using new and delete to allocate the vFile object so that you can control its destruction. Call the _CrtDumpMemoryLeaks() function after the object is destroyed. There shouldn't be a memory leak.
It still says there is a memory leak:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
#include <iostream>
#include <vector>
#include <crtdbg.h> 
using namespace std;

int main()
{
	vector<char*> vFile;

	vFile.push_back(new char ('a'));

	for(unsigned int i = 0; i < vFile.size(); i++)
	{
		delete vFile[i];
	}

	vFile.clear();
	cout << _CrtDumpMemoryLeaks();
	
	system("pause");
return 0;
}
After getting suspicious and doing some tests, I have come to the conclusion that
_CrtDumpMemoryLeaks(); cannot be used with c++ classes
(at least NOT in the way we are trying to use it anyway)

My reasoning is as follows:
C++ classes have destructors. The distructor will be called after the closing
bracket of the function (in this case main function).
The _CrtDumpMemoryLeaks(); function is inside
the closing bracket, therefore it does it's leak check BEFORE the destructor is called.

For C style memory allocation where you only use functions like malloc , you should have called free by the time your function is about to finish (which is why you put _CrtDumpMemoryLeaks(); as the last line before the closing brace or last line before a return statement).


As jsmith said, the vector still has the memory.

Try
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#include <iostream>
#include <vector>
#include <crtdbg.h> 
using namespace std;

int main()
{
    {
	vector<char> vFile;
	vFile.push_back('a');
	vFile.clear();
    }
    cout << _CrtDumpMemoryLeaks();
    system("pause");
    return 0;
}
translore, you are missing the whole point of what I said. The vector is still allocated on the stack. Therefore even though you delete the character the vector still has memory that was allocated after the clear call. I didn't suggest dynamically allocating what you insert into the vector. I suggested dynamically allocating the vector itself. The only difference is that in your second example, the vector allocated memory to hold a copy of the pointer to the char instead of the character itself. Deleting the character will have no effect on the memory that was allocated inside the vector.
guestgulkan:

So the way to get around the problem is this:

1
2
3
4
5
struct MemCheck {
   ~MemCheck() {
        _CrtDumpMemoryLeaks();
   }
};


And then instantiate MemCheck as the first variable in the block/function so that it gets destroyed last, after everything else.
kbw that method is really nice, makes debugging much easier.
I actually did it is a global variable ( which might be ok if it is the only global varaible, but could be issues if there is more than one gobal as there is no guaranteed construction/destruction order for gloabls, so thes's no guarantee it would be the last variable destructed).

Topic archived. No new replies allowed.