2

Possible Duplicate:
C++ delete - It deletes my objects but I can still access the data?

consider the following code:-

#include <iostream>
class Test
{
public:
    int k=10;
};

int main(int argc, const char * argv[])
{
    Test *t = new Test();
    delete t;
    //t1 = NULL;
    t->k=50;
    printf("\n%d",t->k);
    return 0;
}

Its output is 50 although t is deleted. Why it's not crashing? I am using Xcode in Mac OS x.

Community
  • 1
  • 1
dkumar
  • 33
  • 4
  • Because that memory is not really deleted, it is only marked as "free", using it does not crash program before it is allocated for other purpose – Aladdin Nov 05 '12 at 05:27

3 Answers3

2

"delete" would only inform (apart from calling the destructor) the Heap manager that the block of memory of sizeof(Test) which was allocated previously using new would not be used anymore and heap manger is free to do anything with that block of memory.

Let me try to give you a scenario on when the same code could cause an exception.

Let us say if the block of memory was allocated by heap manager on a new memory page which the heap manger acquired from the virtual memory manager, because it could not find free space anywhere else in the previously allocated pages. And now when delete is done heap manager would find that the only block which was allocated on the memory page is released, so it MIGHT decide to release the memory page back to virtual memory manager. And then when your code goes and access the memory whose page does not even exist in the virtual memory you would get an error.

Of course there are other scenarios one can come up with through a good knowledge of heap management implementations.

nanda
  • 804
  • 4
  • 8
1

Because you're (un)lucky. You're invoking undefined behaviour. One possible undefined behaviour is 'working as you expect'. However, your expectations are dubious. Add a function call between the delete and the use where that function allocates memory and so on, and you may completely wreck some other data with you're ill-judged assignment.

Undefined behaviour doesn't have to crash...or doesn't have to crash immediately. But invoking it will usually lead to problems in the long run, especially in bigger programs.

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
0

That's an undefined behaviour you shouldn't expect anything. However, the memory has probably not been written yet, it was just marked as free, it will be over written eventually, that's probably why it's working. It is a good practice to set the pointer to NULL, to avoid such pitfalls, see the dangling pointer problem.

iabdalkader
  • 17,009
  • 4
  • 47
  • 74
  • will it remove from memory? Is t=NULL ; Neccessary – dkumar Nov 05 '12 at 05:26
  • @dkumar not right away, but it will be written over eventually – iabdalkader Nov 05 '12 at 05:28
  • @dkumar: the OS will reclaim the memory when required. It is a practice to set it to NULL so that no one accidentally tried to access it after it has been deleted. Therefore a 'NULL' check is used to identify if the pointer holds a valid memory address – mots_g Nov 05 '12 at 05:29
  • @mux when will this eventually actually work? Will it not lead to more allocated memory in run-time. It crash in Visual Studio. Does they use different alloc and dealloc mechanisms? – dkumar Nov 05 '12 at 05:37
  • @dkumar it may or may not crash that's why it's called an (undefined) behaviour. and you shouldn't do that. – iabdalkader Nov 05 '12 at 05:41
  • 1
    @dkumar -- the memory is deallocated right away--it's available for reuse immediately. You're not leaking memory. But, just because it's _available_ for reuse doesn't mean it will be reused right away. – nielsbot Nov 05 '12 at 05:43