Question

Alright, I think we all agree that what happens with the following code is undefined, depending on what is passed,

void deleteForMe(int* pointer) {      delete[] pointer; } 

The pointer could be all sorts of different things, and so performing an unconditional delete[] on it is undefined. However, let’s assume that we are indeed passing an array pointer,

int main() {      int* arr = new int[5];      deleteForMe(arr);      return 0; } 

My question is, in this case where the pointer is an array, who is it that knows this? I mean, from the language/compiler’s point of view, it has no idea whether or not arr is an array pointer versus a pointer to a single int. Heck, it doesn’t even know whether arr was dynamically created. Yet, if I do the following instead,

int main() {      int* num = new int(1);      deleteForMe(num);      return 0; } 

The OS is smart enough to only delete one int and not go on some type of ‘killing spree’ by deleting the rest of the memory beyond that point (contrast that with strlen and a non-\0-terminated string — it will keep going until it hits 0).

So whose job is it to remember these things? Does the OS keep some type of record in the background? (I mean, I realise that I started this post by saying that what happens is undefined, but the fact is, the ‘killing spree’ scenario doesn’t happen, so therefore in the practical world someone is remembering.)

Answer 1

The compiler doesn’t know it’s an array, it’s trusting the programmer. Deleting a pointer to a single int with delete [] would result in undefined behavior. Your second main() example is unsafe, even if it doesn’t immediately crash.

The compiler does have to keep track of how many objects need to be deleted somehow. It may do this by over-allocating enough to store the array size. For more details, see the C++ Super FAQ.