-3
#include<iostream>
#include<conio.h>

using namespace std;

class Marie{

public:
    int x;

    Marie(){
        cout<<"created";
    }

    ~Marie(){
        cout<<"hii i am destructor";
    }

    void ShowMarie() {
        cout<<"friends";
        x=5;
        delete this;  /*<--- here destructor called */
    }
};

int main(){
    Marie *ptr = new Marie;

    ptr->ShowMarie();

    cout<<ptr->x; /*<---- ptr is dangling pointer but it is still showing me the correct value.*/
    getch();
}
  1. After calling the destructor for the object, it's still referencing as if it is in the memory? why?
  2. And why do we need to call the destructor explicitly for a dynamically created object by using delete this?
  3. If we use delete this; inside destructor what will happen? Is this making the call to destructor recursively?
Praetorian
  • 106,671
  • 19
  • 240
  • 328
tusharRawat
  • 719
  • 10
  • 24
  • 4
    Dereferencing a deleted pointer in `cout << ptr->x` is *undefined behaviour*, anything could happen. It could teleport you to the gates of hell, but this time it happened to print the old value. *"Why do we need to do `delete`"* You should look it up, it was explained a lot of times before. *"`delete this;` inside destructor"* Yes, most probably it will cause stack overflow because of the endless recursion. – HolyBlackCat May 08 '18 at 16:39
  • 2
    And don't use Turbo C++. Get Visual Studio or MinGW, they're both free. – Praetorian May 08 '18 at 16:43
  • As to why `cout << ptr->x` after `delete` often works: `delete` calls the destructor and tells the compiler it's free to reuse the memory when it wants to. The compiler doesn't have to reuse right away. – HolyBlackCat May 08 '18 at 16:49
  • First duplicate though it is about local variable not dynamically allocated one explains main principle - why memory is still accessible. Second one already answers why dynamic memory accessible after deallocation. – Slava May 08 '18 at 17:09

2 Answers2

1

After calling the destructor for the object, it's still referencing as if it is in the memory? why?

Deleting a pointer doesn't zero out any memory because to do so would take CPU cycles and that's not what C++ is about. What you have there is a dangling pointer, and potentially a subtle error ... (Benj answer).

And why do we need to call the destructor explicitly for a dynamically created object by using delete this?

Calling the destructor manually is required if the object was constructed using an overloaded form of operator new(), except when using the "std::nothrow" overloads... (Dietmar Kühl answer).

If we use delete this; inside destructor what will happen? Is this making the call to destructor recursively?

As soon as the destructor is called (the first time), the lifetime of the object has ended. Thus, if you call the destructor for the object from within the destructor, the behavior is undefined ... (James McNellis answer).

Please in your future search(es) use the stackoverflow database, most of the time there is already an answer to your question.

Ashlanfox
  • 59
  • 9
0
  1. Dereferencing a deleted pointer is undefined behaviour. In your example, it just happens that the memory where the object pointed by ptr hasn't been overwritten thus, it is still in the memory.
  2. When creating an object dynamically, you are reserving that memory and it will remain reserved till you reclaim it using delete.
  3. My best guess is that yes, it will call the destructor recursively till there is a stack overflow.
Anzurio
  • 16,780
  • 3
  • 39
  • 49