Accessing member function after calling delete to an object

Question

Someone please explain this . So far I know, I can not access an allocated memory after deleting it. If I am wrong please correct me.

#include <iostream>

using namespace std;

class A
{
    int x;
public:
    A()
    {
        x = 3;
        cout<< "Creating A" <<endl;
    }

    ~A()
    {
        cout<< "Destroying A" <<endl;
    }

    int getX()
    {
        return x;
    }
};


int main(int argc, const char * argv[])
{
    A* a = new A();
    delete a;
    cout<< a->getX()<<endl;

    return 0;
}

And the output shows as follows !

Creating A
Destroying A
3

I don't understand how can I call getX() after deleting a

Undefined behavior. Anything can happen and what you are seeing is one case of the behavior. — Mahesh, Sep 08 '13 at 17:22
How many times is this going to be asked yet? (Oh, and honestly, why are people trying to get an explanation about the nonsense?) — , Sep 08 '13 at 17:24
There is no "Possibilities". What happens in "undefined" which literally means "who the heck knows, just don't do it" — IdeaHat, Sep 08 '13 at 17:26
http://stackoverflow.com/questions/6441218/can-a-local-variables-memory-be-accessed-outside-its-scope — Jack Aidley, Sep 08 '13 at 17:26
Not too different from [Can local variable's memory be accessed outside its scope?](http://stackoverflow.com/questions/6441218/can-a-local-variables-memory-be-accessed-outside-its-scope) — David Rodríguez - dribeas, Sep 08 '13 at 17:27
@H2CO3 may be because they think its a brain teaser for interviews :D — P0W, Sep 08 '13 at 17:28
@P0W I would immediately fire any HR people if they asked about UB in a way that the candidate had to explain the outcome of UB. — , Sep 08 '13 at 17:29
@H2CO3: You may want the candidate to know its undefined behavior. — Martin York, Sep 08 '13 at 17:41
@LokiAstari Obviously. But not require him to reason about the unreasonable. — , Sep 08 '13 at 17:41

Uchia Itachi · Answer 1 · 2013-09-08T17:33:13.307

You're a victim of undefined behavior. When they say it is undefined behavior it means anything could happen and that includes the code might appear to work correctly.
When you release a dynamically allocated memory the memory isn't erased up. It means that your current process doesn't own it, but the contents remain there until they are reused for something else.

But accessing the unallocated memory is fatal.

And also, when you release the memory by delete a it frees the memory help by a, but a is still in scope and has its lifetime until end of main.
Hence you're able to perform the function call. Deleting the memory doesn't destroy the variable itself but the memory held by the variable is cleaned up. Non-dynamic variables are destroyed by the compiler when their lifetime ends.

*the code might turn out to behave* correctly *also* -- there is no *correct* behavior for undefined behavior, that would be better described as "behave as *expected*" or "appear to work" — David Rodríguez - dribeas, Sep 08 '13 at 17:29

score 1 · Answer 2 · answered Sep 08 '13 at 17:25

1

This is an undefined behavior, anything may happen. If the memory block is not yet filled with something else it may not crash as you seen, but please, do not access to freed memory !

And do not use raw pointer, we create smart pointers for that purpose.

answered Sep 08 '13 at 17:25

galop1n

8,573
22
36

I don't see anything in this question that would warrant having a smart pointer. Why not just have the object? – us2012 Sep 08 '13 at 17:27
Nothing in the question that warrants smart pointers. – Casper Beyer Sep 08 '13 at 17:29

score 0 · Answer 3 · answered Sep 08 '13 at 17:26

0

The behavior is undefined. Anything can happen in my implementation the program is showing up a garbage value. Actually the standard does not define anything, implementations are free to choose anything

answered Sep 08 '13 at 17:26

deeiip

3,319
2
22
33

Accessing member function after calling delete to an object

3 Answers3