This is code from an exercise:
#include <iostream>
using namespace std;
int main() {
int n = 13;
int* ip = new int(n + 3);
int* ip2 = ip;
cout << *ip << endl;
delete ip;
cout << *ip2 << endl;
cout << ip << tab << ip2 << endl;
}
When the space allocated to the int on the heap is deleted, I thought that dereferencing the pointer would give some sort of memory error. Instead, it returns 0.
Why is this?
Dereferencing an invalid pointer leads to undefined results per spec. It's not guaranteed to fail.
Usually (CPU/OS/compiler/... dependent), the compiler doesn't really care about it at all. It just gives what's currently at that memory address. For example, in x86 architecture, you just see an error only when the address is in a memory page that's not mapped to your process (or your process doesn't have permission to access that), thus an exception will be thrown by the CPU (protection fault) which the OS would handle appropriately (and probably, making your process fail). A trick is sometimes used to make accessing the address 0 always cause an access violation: The OS sets the read/write bits of the first page of the address space in the page table to 0 so that any access to that page will always generate an exception.
This behaviour is undefined, and so what will happen is implementation and system dependent.
Dereferencing the ip pointer will return what happens to be at that memory location at that time.
It's returning 0 because that's what the four bytes at ip happen to encode to when cast as an integer.
dereferencing a pointer after it's been deleted is unpredictable. It might be zero, it might be something else if that memory has been reallocated elsewhere.
You're just lucky that it's 0 when you run your program.
Further to Mehrdads answer, In gcc with glibc, the data structures representing the memory heap are stored in the block of memory returned, to save memory (i.e. its an intrusive list). So, when a block of memory is freed, it is added to the free list. My guess is that the 0 being written following the free indicates that this is the last element of the the free block list (the first pointer sized word of deallocated memory will contain the lists next pointer).
If you were to allocate and free more memory before dereferencing this block again, the value would change when a new item is added to the end of the free list. This is one way that library implementation decisions affect what happens during 'undefined' behaviour. In this case, the glibc developers have taken advantage of the fact that this behaviour is undefined to make their memory allocator more space efficient.
If you run your program under valgrind, it will catch these errors for you. In any case, always stay away from undefined behaviour, since it is very likely to be different on various platforms and even different builds on the same platform (e.g. debug vs release).