I have written a simple, working tetris game with each block as an instance of a class singleblock.
class SingleBlock
{
public:
SingleBlock(int, int)
Yes, it can be expected at times. Whereas new
reserves space for data, delete
simply invalidates a pointer created with new
, allowing data to be written at the previously reserved locations; it doesn't necessarily delete the data. However, you shouldn't rely on that behaviour because the data at those locations could change at any time, possibly causing your program to misbehave. This is why after you use delete
on a pointer (or delete[]
on an array allocated with new[]
), you should assign NULL to it so that you can't tamper with an invalid pointer, assuming you won't allocate memory using new
or new[]
before using that pointer again.
The system does not clear the memory when you release it via delete()
. The contents are therefore still accessible until the memory is assigned for reuse and overwritten.
Although it's possible that your runtime doesn't report this error, using a proper error-checking runtime such as Valgrind will alert you to the use of memory after it has been freed.
I recommend that if you write code with new
/delete
and raw pointers (rather than std::make_shared()
and similar), that you exercise your unit tests under Valgrind to at least have a chance of spotting such errors.
Well, I have been wondering about this for quite a while as well, and I have tried to run some tests to better understand what's going on under the hood. The standard answer is that after you call delete you should not expect anything good from accessing that memory spot. However, this did not seem enough to me. What is it really happening when calling delete(ptr)? Here's what I've found. I'm using g++ on Ubuntu 16.04, so this may play a role in the results.
What I first expected when using the delete operator was that the freed memory would be handed back to the system for usage in other processes. Let me say this does not happen under any of the circumstances I have tried.
Memory released with delete still seem to be allocated to the program it first allocated it with new. I have tried, and there is no memory usage decrease after calling delete. I had a software which allcated around 30MB of lists through new calls, and then released them with subsequent delete calls. What happened is that, looking at the System monitor while the program was running, even a long sleep after the delete calls, memory consumption my the program was the same. No decrease! This means that delete does not release memory to the system.
In fact, it looks like memory allocated by a program is his forever! However, the point is that, if deallocated, memory can be used again by the same program without having to allocate any more. I tried to allocate 15MB, freeing them, and then allocating another 15MB of data after, and the program never used 30MB. System monitor always showed it around 15MB. What I did, in respect to the previous test, was just to change the order in which things happened: half allocation, half deallocation, other half of allocation.
So, apparently memory used by a program can increase, but never shrink. I thought that maybe memory would really be released for other processes in critical situations, such as when there is no more memory available. After all, what sense would it make to let a program keep its own memory forever, when other processes are asking for it? So I allocated the 30MB again, and while deallocating them I run a memtester
with as much physical memory I could. I expected to see my software hand out its memory to memtester. But guess it, it did not happen!
I've made up a short screencast that shows the thing in action:
To be 100% honest, there was a situation in which something happened. When I tried memtester with more than the available physical memory in the middle of the deallocation process of my program, the memory used by my program dropped to around 3MB. The memtester process was killed automatically though, and what happened was even more surprising! The memory usage of my program increased with each delete call! It was just as if Ubuntu was restoring all its memory back after the memtester incident.
Taken from http://www.thecrowned.org/c-delete-operator-really-frees-memory
It won't zero/change memory just yet... but at some point, the rug is going to be pulled from under your feet.
No it is certainly not predictable: it depends on how fast memory allocation/deallocation is churned.
Is being able to access data from beyond the grave expected?
This is technically known as Undefined Behavior. Don't be surprised if it offers you a can of beer either.