2

I'm pretty new to C++. I have to delete the pointer and memory allocation, once I complete the cycle. I am using new() for memory allocation and delete at the end to free the data.

The program is as follows:

int main()
{

    float *ptr;

    ptr = new float[16];

    for(int i=0; i<16; i++) 
    {
        ptr[i] = 10.0f+i;
        cout << i << " " << ptr[i] << endl;
    }

    delete[] ptr;

    cout << ptr[2] << endl;  **// I STILL HAVE THE VALUE AT THIS ADDRESS. AFTER DELETING**

    }

return 0;
}

Why does the data still exist in the memory even after deleting it.

Unihedron
  • 10,902
  • 13
  • 62
  • 72
Uday
  • 45
  • 6
  • 1
    these are garbage values. – Heena Goyal Mar 14 '14 at 11:59
  • 3
    memory is "no longer yours" after the delete, but noone said it had to be wiped out when you free it. Beside, that would be a segmentation fault, your compiler is probably ignoring the "delete []" line because the program ends quickly after... – Exceptyon Mar 14 '14 at 12:07
  • 1
    Values ​​are there but do not represent allocations. Areas are available for new allocations. – lsalamon Mar 14 '14 at 12:08
  • Memory doesn't just disappear. What would you have expected to happen? – fredoverflow Mar 14 '14 at 12:22
  • http://stackoverflow.com/questions/6441218/can-a-local-variables-memory-be-accessed-outside-its-scope isn't quite teh same but the first answer is enlightening – jcoder Mar 14 '14 at 12:40
  • This question is _not_ a duplicate of either of the two cited questions. This is asks why the values remain after the memory is released. The first cited question is about object lifetimes, and the solution has nothing to do with this question. The second cited question is not about dynamic memory. – Adrian McCarthy Mar 14 '14 at 20:06

1 Answers1

4

This is undefined behavior. You are accessing memory after you have deleted it.

Because deleting a block of memory does not zero the value of all pointers that point to it. Deleting memory merely makes a note that the memory is available to be allocated for some other purpose. Until that happens, the memory may appear to be intact -- but you can't count on it. And on some compiler/runtime/architecture combinations, your program will behave differently.

Two things happen when delete[] is called:

  1. If the array is of a type that has a nontrivial destructor, the destructor is called for each of the elements in the array, in reverse order
  2. The memory occupied by the array is released

Accessing the memory that the array occupied after calling delete results in undefined behavior (that is, anything could happen--the data might still be there, or your program might crash when you try to read it, or something else far worse might happen).

Use RAII. Either wrap it in a class or use the STL and don't manage memory yourself. C++ is powerful, but you can also blow your leg off - so to speak. A better practice would be to put it in its own scope would prevent anything beyond the scope from accessing your pointer.

{
    Foo* pFoo = new Foo;
    // use pFoo
    delete pFoo;
}
// anything using pFoo beyond here fails at compilation
Engineer2021
  • 3,288
  • 6
  • 29
  • 51
  • 1
    This is all good advice, but it doesn't seem to answer the question, which is _why_ the values are still visible. Someone new to the language may not understand what "undefined behavior" really means. – Adrian McCarthy Mar 14 '14 at 12:08
  • @AdrianMcCarthy: It's UB.. anything goes – Engineer2021 Mar 14 '14 at 12:08
  • 1
    @AdrianMcCarthy: My edit may assuage any concerns – Engineer2021 Mar 14 '14 at 12:10
  • 1
    "It's UB..anything goes." You know that. We know that. The asker might not comprehend. The edit is better I suppose. *Deleting memory merely makes a note that the memory is available to be allocated for some other purpose.* That is not accurate. On some implementations it might be true. But on others, it will not be true. – David Heffernan Mar 14 '14 at 12:15
  • 1
    @GIJoe Thanks! I'm clear now. I was concerned, of building up the memory before. Thanks! – Uday Mar 14 '14 at 13:51