I came across this kind of code once in a while - I suspect the creator is/was afraid that table delete would iterate over the table and "cost performance" (which imho will not be done either way)... is there any real benefit one might get/consider/imagine from not using the the table delete here?
myClass** table = new myClass* [size];
... //some code that does not reallocate or change the value of the table pointer ;)
delete table; // no [] intentionally
Not only is there no benefit, the code is just plain wrong -- at best, it leaks memory, and at worst, it can crash your program or open up a hard-to-find security hole. You must always match
new
withdelete
andnew[]
withdelete[]
. Always.If you do this, you will get what the C++ Standard calls undefined behaviour - anything could happen.
There's really no reason to write like that and a serious reason to never do so.
It's true that for types with trivial destructors (like raw pointers in your case) there's no need to know the actual number of elements in the array and so the compiler might decide to map new[] and delete[] onto new and delete to reduce the overhead. If it decides this way you can't stop it without extra steps taken, so this compiler optimization will take place without your notice and will be free.
At the same time someone using your code might wish to overload the global operators new and delete (and new[] and delete[] as well). If that happens you run into big trouble because this is when you may really need the difference between the delete and delete[].
Add to this that this compiler-dependent optimization is unportable.
So this is the case when you get no benefits displacing delete[] with delete but risk big time relying into undefined behaviour.
In theory you should call delete [].
EDIT: The following applies only to Microsoft Visual C++ (I should have said this).
In practice, in Microsoft Visual C++ , it doesn't matter which delete you use when the objects in the array don't have destructors. Since you have an array of pointers, and pointers can't have destructors, you should be OK.
However, as others have pointed out, it is incorrect C++ to mix new [] and delete without []. Although it may work in Visual C++ in this case, the code is not portable and may fail in other compilers.
But going back to the specific case of Visual C++, even if you call delete [], the compiler will realize that it doesn't need to iterate through the array calling destructors when it's an array of primitive types like int, char, or pointers. Calling delete in that case actually works and won't break anything. It would not be slower to do the right thing and call delete [], but it won't be faster either.
In fact, in MSVC++, delete[] p immediately calls the regular operator delete(void *p) when p is a pointer to a simple type, or one without destructors.
Those who don't believe me, step through this code into the CRT code for the first two calls to delete[].
That is a memory leak. A
new []
must be matched by adelete []
. Further, sincetable
is a pointer to the first element of an array of pointers, any array member, if it's an array by itself will need to be de-allocated using adelete []
.It's definitely wrong as a s new[] needs to be paired with delete[]. If you don't you will get undefined behavior.
It may work (partially), because most implementations use new to implement new[]. The only difference for such an implementation would be that it would only call 1 destructor (for the first element instead of all destructors. But avoid it as it is not legal c++.