hi there i've got the following code to test on, you can try it on your computer aswell

int a=0;
char* array = new char[1000];
int b=0;
delete[] array;
int c=0;

ive placed breakpoints on all rows and steps my way through during debugmode
in taskmanager in windows i look at how much memory my application is using and after it excecuted row 2 the memoryusage increases but after it excectued row 4 the memoryusage doesnt decrease. its as if delete[] had no effect

however if i increase the size of the array to 1000000 the memoryusage does decrease and its as if delete[] is doing what its supposed to.

i can imagine that therse some sort windows memory usage optimization algorithm lying in the background causing this problem.
and the problem is that there's no way to test for small memory leaks if theres no change in the memoryusage reading.

my question is when does the "small" memory get deleted by the OS? this might be a hard question and possibly i posted this in the wrong category but this is a problem i have when i program in C++

Hi ColacX,

while freeing memory the variable memory will move to garbage, the garbage collector will keep the memory, when ever you initializing the new variable are pointer on your program the memory for those variable are use the garbage collector, if garbage collector not having enough memory then only the compiler assign a new memory location.

Try to check!!!

There is no garbage collector in C/C++, unfortunately. The effect which is seen by the original poster is explained by a virtual memory concept in Windows OS. The memory is allocated/released by pages and each page is 4096 bytes long. Small memory blocks will come from local heap and it is always in physical memory - this is why freeing memory is not "visible". Large memory will require additional pages of 4096 bytes to be allocated from OS and freeing that memory will be indeed visible.

For detecting memory leaks - there is a function in Visual Studio:
http://msdn.microsoft.com/en-us/library/d41t22sb(VS.80).aspx

Using Task Manager to detect leaks is a very random process - the small leaks will go unnoticed. Here is a small example: open Visual Studio and in the middle of working in some development process look at Task Manager - Studio will take about 25-40Mb of memory - depend on a size of a solution. Now, minimize the Studio and see the memory now. OS will free some pages back to the system pool - sometimes a lot of megabytes. This happens for every Windows program.

To detect real leaks - call that function at the very end of the program and it will report leaks if any found. Sometimes there is an information which points to a code line and file, so leak can be easily followed. When this information is missing, then to find the actual leak in code is some more work to be done. Leak usually has an allocation number attached to it, but these numbers are not very precise if MFC code is running. In such case to locate a leak you must hook the allocations and in a hook function you should trace block of leaked size and have internal static count for these blocks. When you run the program - you will see the internal blcok count in trace - put a breakpoint in your hook at the specified allocation number and run the code again - this time it will stop in your hook function and by looking at stack trace you will finally discover the code place where block is leaking.

Thanks for replies very helpful i understand now.

Detected memory leaks!
Dumping objects ->
{68} normal block at 0x00294DD8, 8 bytes long.
Data: < > 00 00 00 00 00 00 00 00
Object dump complete.

how do i trace the memoryleaks from memoryaddress to c++code? sometimes you can see it from the size of the memory leak but other times?

: Detected memory leaks!
: Dumping objects ->
: {68} normal block at 0x00294DD8, 8 bytes long.
: Data: < > 00 00 00 00 00 00 00 00
: Object dump complete.
:
: how do i trace the memoryleaks from memoryaddress to c++code?
: sometimes you can see it from the size of the memory leak but other
: times?
:


If your application is not MFC application, then write that statement at the very beginning of your program:

#include <CrtDbg.h>

int main ()
{
    _CrtSetBreakAlloc (68); // <-- Break when block #68 is allocated
    //
    // ... rest of your code ...
    //
}

Notice that I am passing value 68 to that function - it is the number of memory block which is leaked and is reported in your leak trace: "{68}".

When you run it, the debugger will stop in memory allocation routine. When it stops - look at the Call Stack window and you will see the trace of function calls leading to that place. It would be a few places down the trace - double click on trace item and you should see what code of yours caused the leaked allocation.

Awesome thank you