1

I am relatively new to programming so this may well sound like a stupid question to you seasoned pros out there. Here goes:

In C++, when I use the delete operator on arrays, I have noticed that the data contained in the released memory locations is preserved. For example:

int* testArray=new int[5];
testArray[3]=24;
cout<<testArray[3]; //prints 24
delete [] testArray;
cout<<testArray[3]; // still prints 24

Subsequently, am I right in assuming that since testArray[3] still prints 42 , the data in the deleted memory location is still preserved? If so, does this notion hold true for other languages, and is there any particular reason for this?

Shouldn't "freed" memory locations have null data, or is "free memory" just a synonym for memory that can be used by other applications, irrespective of whether the locations contain data or not?

I've noticed this is not the case when it comes to non array types such as int, double etc. Dereferencing and outputting the deleted variable prints 0 rather than the data. I also have a sneaking suspicion that I might be using wrong syntax to delete testArray, which will probably make this question all the more stupid. I'd love to hear your thoughts nonetheless.

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
Zubizaretta
  • 157
  • 1
  • 9
  • Your syntax to delete the array is correct.Just that you have created an **Undefined Behavior(UB)** in your program by accessing a `delete`d memory.Due to to the UB you don't see the expected/assumed output. – Alok Save Nov 20 '11 at 12:28
  • 1
    [Your bible wasn't touched.](http://stackoverflow.com/questions/6441218/can-a-local-variables-memory-be-accessed-outside-its-scope/6445794#6445794) – Kerrek SB Nov 20 '11 at 12:39

3 Answers3

2

The data is still there, because when you free, it frees it in the allocation table -- the system would be very slow if it had to zero over all the memory each time free() or delete is called.

This is the same in any language.

I think the non-array types were set to zero because they were in fact statically allocated rather than dynamically allocated.

Anthony Blake
  • 5,328
  • 2
  • 25
  • 24
  • That would mean the program never gives any memory back to the OS (because it would not be accessible then). I don't think that is the behaviour of all languages. – Patrick Nov 20 '11 at 12:03
  • @Patrick Huh? The part where I said "it frees it in the allocation table" means it is given back to the OS – Anthony Blake Nov 20 '11 at 12:14
2

Once you deallocate the memory by calling delete and try to access the memory at that address again it is an Undefined Behavior.

The Standard does not mandate the compilers to do anything special in this regard. It does not ask the compilers to mark the de-allocated memory with 0 or some special magic numbers.It is left out as the implementation detail for the compilers. Some compiler implementations do mark such memory with some special magic numbers but it is left up to each compiler implementation.

In your case, the data, still exists at the deallocated addresses because perhaps there is no other memory requirement which needed that memory to be re-utilized and the compiler didn't clear the contents of previous allocation(since it is not needed to).

However, You should not rely on this at all as this might not be the case always. It still is and will be an Undefined Behavior.

EDIT: To answer the Q in comment.
The delete operator does not return any value so you cannot check the return status however the Standard guarantees that the delete operator will sucessfully do it's job.

Relevant quote from the C++03 Standard:
Section §3.7.3.2.4:

If the argument given to a deallocation function in the standard library is a pointer that is not the null pointer value (4.10), the deallocation function shall deallocate the storage referenced by the pointer, render-ing invalid all pointers referring to any part of the deallocated storage.

Alok Save
  • 202,538
  • 53
  • 430
  • 533
2

non-POD data will be altered in a destructor (which might appear as being null-ed in a debugger).

Freed data is just usable, indeed.

You can NOT depend on the data being unaltered after delete. On a related note, debugging malloc's or runtime libraries will frequently reset the data to a specific signature (0xdeadbeef, 0xdcdcdcdc etc) so you can easily spot accesses to deleted memory in a debugger.

sehe
  • 374,641
  • 47
  • 450
  • 633