8
int* arr = new int[count];

delete arr;

Why does this work? I've checked and it actually frees the memory. From what I've read I need delete[] arr; otherwise it won't actually free all the memory.

Farzher
  • 13,934
  • 21
  • 69
  • 100
  • 3
    "Why does this work?" - it doesn't, it just appears to be working. –  Aug 04 '13 at 19:10
  • Without the brackets, you're calling just one destructor, not all the destructors in the array. Also see http://stackoverflow.com/questions/2425728/delete-vs-delete-operators-in-c – SaganRitual Aug 04 '13 at 19:13
  • 1
    It works since delete and delete[] have the same result for POD-types. NO MEMORY LEAK in this case. But if NOT POD-types, the program will be crashed (only first element will be destructed, it leads to Memory leak). You can try with Valgrind to gain insight into this issue – Hoang Pham Nov 24 '18 at 20:25

3 Answers3

14

The difference is not whether or not the allocated memory is properly freed - whether you use

delete

or

delete[]

the memory will still be properly deallocated.

The difference is whether or not the destructors will be properly invoked.

delete // will only invoke the destructor of the first element of the array.

delete[] // will invoke the destructor for *each* element of the array.

This has no practical effect for primitive types like int or float, but when you have an array of some class, the difference can be critical.

Zenilogix
  • 1,318
  • 1
  • 15
  • 31
  • 1
    I can imagine an implementation where this would be true. Do you have actual documentation of an implementation that shows this to be true? – sehe Aug 04 '13 at 20:35
  • 2
    No docs, only my own experience in this is with Visual C++. Been a while, but I remember facing bugs because I wrongly used delete instead of delete[]. Pretty sure it behaved as I described... bear in mind that *x dereferences the same location as x[0], and declaring x as a pointer to whatever says nothing about whether the target object is scalar or array, so the delete operator won't know it has to destruct an array of object vs a scalar object unless you tell it to via appropriate delete construct. – Zenilogix Aug 05 '13 at 01:25
10

Now try it with filling the array with strings of 100 bytes each, and see if it still frees all the allocated memory...

It is undefined behaviour, and as always, sometimes UB will appear to work. In your case, you have no destructor for the objects in the memory, so there is no "further work", just free all the memory [1]. But if you have an object that has a destructor that does something useful, it (probably) won't get called.

You should ALWAYS use delete [] if you used new T[size]; to allocate. Don't mix the two, it's always wrong - just sometimes it HAPPENS to work [just like SOME sizes of spanners in inches works on mm nuts and vice versa - but it's still wrong to use a inches spanner set on metric nuts].

[1] Note that this may work for this particular compiler/C++ library combination. Compiling it with a different compiler, using a different C++ library, or compiling for a different OS may cause it to crash when you try the same thing.

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
3

delete and delete [] are actually different operators and to use the wrong one is always an error. The problem is that it often seems fine at the time, but the heap has ben corrupted and you are very likely to experience an apparently unrelated crash later.

David Elliman
  • 1,379
  • 8
  • 15
  • I don't understand why I am being marked down for this as it is TRUE. You could try running valgrind or a similar memory analysis tool and it will show the heap corruption when it happens. – David Elliman Aug 04 '13 at 19:27
  • 1
    I hope downvoters comment. I'm interested which part may not be correct. – Minimus Heximus Aug 04 '13 at 19:38
  • I don't know why- this is a completely accurate answer. – Puppy Aug 04 '13 at 19:41
  • You cannot state "the heap has been corrupted". It _might_ not have been. It's _undefined_. – sehe Aug 04 '13 at 19:41
  • 2
    @sehe: I think the entire rest of the sentence is intended to be modified by the "often". – Jerry Coffin Aug 04 '13 at 19:42
  • @DavidElliman What sehe said. You're basically saying "this *will* happen" when in actuality this is undefined behavior. This is likely to happen but you cannot affirm that this will be the case. – Borgleader Aug 04 '13 at 19:43
  • It won't necessarily crash later as you may not reuse that portion of the heap - so yes it is undefined, but it is a land mine you are very likely to step on later. – David Elliman Aug 04 '13 at 19:54