( POD )freeing memory : is delete[] equal to delete ?

Question

IP_ADAPTER_INFO *ptr=new IP_ADAPTER_INFO[100];

if i free using

delete ptr;

will it lead to memory leak, if not then why ?

This is disassembly code generated by VS2005

**delete ptr;**
0041351D  mov         eax,dword ptr [ptr] 
00413520  mov         dword ptr [ebp-0ECh],eax 
00413526  mov         ecx,dword ptr [ebp-0ECh] 
0041352C  push        ecx  
0041352D  call        operator delete (4111DBh) 
00413532  add         esp,4 
    **delete []ptr;**
00413535  mov         eax,dword ptr [ptr] 
00413538  mov         dword ptr [ebp-0E0h],eax 
0041353E  mov         ecx,dword ptr [ebp-0E0h] 
00413544  push        ecx  
00413545  call        operator delete[] (4111E5h) 
0041354A  add         esp,4

Answer 1

This FAQ answers exactly this question.

Answer 2

If A points to an array that was allocated via new T[n], then you must delete it via delete[] A.

Why?

The difference between delete and delete[] is straightforward - the former destroys a scalar object and the latter destroys an array.

More info here and here.

UPDATE 1 (wrong):

If you use delete (and not delete[]) while allocating with new T[n], only first element is freed while others are not destructorized, which will lead to memory leak. Why? This is the way Bjarne Stroustrup and others had designed the language. And it is not compiler-varying. If one compiler deallocates the different way, it is just not following the standard. The C++ Programming Language, chapters 6.2.6.2 and 19.4.5.

UPDATE 2 (correct):

I'm admitting my mistake about behavior of using delete operator on allocations with new T[n]. Reading the mentioned document I didn't find the exact description so I suppose in this situation the behavior will be undefined and will vary on from compiler to compiler. AFAIK, MSVC compiler for example will produce different code than GCC. Please ignore UPDATE 1.

Answer 3

Whether this leads to a memory leak, wipes your hard disk, gets you pregnant, makes nasty Nasal Demons chasing you around your apartment, or lets everything work fine with no apparent problems, is undefined. It might be this way with one compiler, and change with another, change with a new compiler version, with each new compilation, with the moon phases, your mood, or depending on the number or neutrinos that passed through the processor on the last sunny afternoon. Or it might not.

All that, and an infinite amount of other possibilities are put into one term: Undefined behavior:

Just stay away from it.

Answer 4

Yes it will Leak.

You need to use delete [] for it to understand that it is an array and that it should follow the pointer and delete the underlying objects.

IF you just use delete myArrayPointer it will Only delete the actual pointer and not the things that it is pointing At.

Answer 5

It will usually not leak because in case of POD destructors are trivial and there's no need for invoking them so delete just deallocates memory occupied by the array. Memory deallocation requires just a pointer value so it will be returned to the heap. The array accopies a contiguous block of memory and so the deallocation can be sucessful just as if it was a deallocation of a single element.

But don't rely on this since it is undefined behaviour. Maybe it works allright, maybe something horrible happens, works on this compiler, doesn't work on another and many people thank you for planting an error.

See this answer for details.

Answer 6

For array of POD it will not leak (with the most compilers). For example, MSVC generates identical code for delete and delete[] for array of POD.

Personally, I think C/C++ could be without operator delete[]. Compiler knows object size and allocated memory size is known at runtime, thus it is very simple to know is a pointer array or not and dispose memory in a right way.

EDIT:

OK, guys. Can you test at your compiler and say whether it leak?

Try to think as a compiler developer. We have new, new[], delete, delete[]. Each new has its own delete. Seems perfect and complete. Let's see what is going on when you call delete[]?

1. call vector destructor for an object
2. actual free memory

What is destructor for POD? Nothing! So, calling delete for array of POD will not leak! Even if it breaks the standard. Even if it is not recommended.

EDIT2:

This is disassembly code generated by VS2008:

operator delete[]:
78583BC3  mov         edi,edi 
78583BC5  push        ebp  
78583BC6  mov         ebp,esp 
78583BC8  pop         ebp  
78583BC9  jmp         operator delete (78583BA3h)

Answer 7

For delete ptr, as others have pointed out, the behaviour is undefined. If you take a minute to compile and run the following:

#include <stdio.h>

static int counter = 0;

class A
{
    private:
     int val;
    public:
    A() {
     this->val = ++counter;
    }
    ~A() {
     printf("value %d\n", this->val);
    }

};

int main(int argc, char **argv)
{
    A *p = new A[10];
    delete p;
    printf("We're done here!\n");
}

with gcc, you'll witness the exact effect of delete on a memory chunk allocated with new[]. :-)

Now, remove the destructor I defined (A is now of a POD class type) and notice what happens.