Why can't I delete other-than-first element from array by pointer

Question

Consider following code:

int main()
{
  int *intArPtr = new int[100];
  int *intArPtr1 = intArPtr + 1;

  delete [] intArPtr; //ok
  //delete intArPtr; //valgrind warning, but no leaks!
  //delete intArPtr1; //invalid pointer error

  return 0;
}

I know that delete [] intArPtr is the only valid way to delete this array, but I'm just curious about following:

1. Why delete intArPtr doesn't yield any memory leaks? Is it undefined behavior and I'm just lucky not to have any?
2. Why delete intArPtr1 gives an error on run-time? Why doesn't it delete all elements but first from the array?
3. How does C++'s runtime knows size of the allocated array (for delete [])? Is it stored somewhere?

Answer 1

1. Why delete intArPtr doesn't yield any memory leaks? Is it undefined behavior and I'm just lucky no to have any?

Correct, it is undefined behavior to call delete on memory allocated with new[]. For one, it won't call the destructors on the array members.

For two, even if you are just asking about memory deallocation and not about object destruction, it's possible for delete and delete[] to be implemented identically, or for them to be different. They read like they're the same thing but they're not: delete and delete[] are two different operators with potentially different implementations. They could use different allocation strategies (see the answer to question #3 below).

2. Why delete intArPtr1 gives an error on run-time? Why doesn't it delete all elements but first from the array?

You have to pass delete a pointer allocated with new. The exact pointer. Not a pointer within a new-allocated memory region, that doesn't work. It has to be the same pointer to the start of the region.

3. How does C++'s runtime knows size of the allocated array (for delete [])? Is it stored somewhere?

A common allocator strategy is to store the number of bytes allocated right before the allocated region. delete would then take the pointer you pass it, look 4 or 8 bytes to the left, and interpret that integer as the size of the region. If you pass it a pointer to somewhere else its lookback strategy will fail.

The C++ language doesn't specify how memory allocation is tracked, so this is an implementation detail. Different standard libraries, compilers, and operating systems will do this differently. What I described is just one possible mechanism.

Further reading:

• C++ FAQ: "What if I forget the [] when deleteing an array allocated via new T[n]?"
• C++ FAQ: "After p = new Fred[n], how does the compiler know there are n objects to be destructed during delete[] p?"

Answer 2

1. Why delete intArPtr doesn't yield any memory leaks? Is it undefined behavior and I'm just lucky no to have any?

Yes and no at the same time. Using delete instead of delete[] is not clean, but usually works. Basically the pointer and offset are both stored at allocation time. This allows a proper deallocation to occur when using delete, even by accident.

2. Why delete intArPtr1 gives an error on run-time? Why doesn't it delete all elements but first from the array?

intArPtr1 does not correspond to the pointer of the allocated area. When trying to delete that, the runtime cannot find this address in the allocation table.

3. How does C++'s runtime knows size of the allocated array (for delete [])? Is it stored somewhere?

It is stored in the allocation table, with the pointer to the allocated area.

Answer 3

Answers:

1. No memory leaks in your exampe. As a matter of fact, deleting array without [] will only cause memory leaks if the objects inside arrays have some memory allocated themselves and are supposed to free that memory in the destructor. In all other cases, improper delete will not cause a memory leak.
2. Because the size of memory allocated is stored just before the pointer. When you are accessing any other element of the array but the first, there is no proper memory size there.
3. See 2.