2

I just wrote a sample program to see the behaviour of delete this

class A
 {
   ~A() {cout << "In destructor \n ";}
 public: 
    int a;
    A() {cout << "In constructor \n ";}

    void fun()
     {
       cout << "In fun \n";
       delete this;
       cout << this->a << "\n"; // output is 0
       this->fun_2(); // how m able to call fun_2, if delete this is called first ??
     }

   void fun_2()
    {
      cout << "In fun_2 \n";
    }

main()
{
 A *ptr = new A;
 ptr->a = 100;
 ptr->fun(); //delete this will be executed here
 ptr->fun_2(); //how m able to execute fun_2 when this pointer is deleted ??
 cout<< ptr->a << "\n"; //prints 0
 return 0;
}

> Output
In constructor
In fun
In destructor
0
In fun 2
In fun 2
0

Questions

  1. After executing delete this in fun(), how I am able to access func_2() with this pointer in fun() ??
  2. Now in main how I am able to do obj->fun_2 as this pointer is deleted ??
  3. If I am able to access function members after killing this object, then why data members are comming zero '0' ??

m using linux ubuntu and g++ compiler

Vikram Singh
  • 273
  • 1
  • 3
  • 10
  • 4
    It's *undefined behaviour*. There's little point asking why something specific is the case, since *anything* could legitimately happen. – Kerrek SB Aug 09 '12 at 16:20
  • 4
    "After driving faster than the speed limit, I was still able to continue driving". You broke the law, buddy. You were "lucky" that nothing happened, but you still broke it. There's nothing in the C++ standard that says "once an object has been deleted, all accesses to the object must be detected and reported as errors". – jalf Aug 09 '12 at 16:20
  • You can access memory off the end of an assigned buffer, too. In both cases, behaviour is undefined. So Don't Do That. – Rook Aug 09 '12 at 16:20
  • Incidentally, you may find it edifying to run your program through Valgrind and see what it has to say. – Rook Aug 09 '12 at 16:23
  • +1, It may be undefined behaviour but it reveals some interesting details about how `g++` implements things. – Gordon Bailey Aug 09 '12 at 16:34
  • possible duplicate of [Can a local variable's memory be accessed outside its scope?](http://stackoverflow.com/questions/6441218/can-a-local-variables-memory-be-accessed-outside-its-scope) – Bo Persson Aug 09 '12 at 16:50
  • http://stackoverflow.com/questions/3422625/accessing-a-local-variable-after-delete-this, http://stackoverflow.com/questions/1866461/why-should-i-not-try-to-use-this-value-after-delete-this – bstpierre Aug 10 '12 at 20:10

2 Answers2

9
  1. What you see is undefined behavior: it might work, or it may crash.
  2. The pointer is pointing to a deleted instance - it is a dangling pointer.
  3. This is an undefined behavior as well: you may see a zero or a garbage value.

Eric Lippert provided a very nice "book in a table drawer of a hotel room" analogy in his answer to a question about pointers to local variables after the function has returned, it is equally applicable here.

Community
  • 1
  • 1
Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523
2

Let's compare that to a similar szenario:

A *a= new A();  
func(a);  
delete a;  
func2(a);  

In my sample the compiler just passes the pointer a to func and func2, it does not care if it is pointing to a valid object. So if you call func2(a) and func2 dereferences the pointer, this is undefined behaviour. The program might crash if the memory was released back to the operating system and the program cannot access *a anymore. Normally delete keeps the memory allocated, does not pass it back to the operating system, so accessing *a after delete will not give an exception, but just return any value. This might be the previous values of *a, but it might also be any other value depending on the implementation of delete and depending on other calls to new done between delete a and *a. MSVC for example sets the memory to a predefined pattern in debug mode so you can easily spot when accessing freed memory.

Why is this related to your question? Because the compilers passes this as a hidden, implicit parameter.

StoryTeller - Unslander Monica
  • 165,132
  • 21
  • 377
  • 458
Werner Henze
  • 16,404
  • 12
  • 44
  • 69