Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

C++ - Does the Destructor just deallocate the memory or does it actually delete the object?

To check this, I have run this small test code.

#include <iostream>
using namespace std;

class name {
public:
  int data;
  name(int data) {
    this->data = data;
  }
  void printData() {
    cout << data << endl;
  }
};

int main() {
  name* namePointer;
  {
    name n(5);
    namePointer = &n;
  }
  namePointer->printData();
}

So, two questions:

  1. The name object n is created in the block inside main and its pointer is saved, to make sure its destructor is called when we get out of the block. But the pointer points to the same object and its member functions are still accessible. Doesn't this mean that the object isn't deleted yet?

  2. Say I add this to my name class:

    ~name() {
        cout << "destructor called" << endl;
    }
    

    Does overriding the destructor function, and doing nothing in it (here in ~name()), prevent the object from being deleted?

Edit: Thanks for the responses, it really helped. But May I know the reason for these down votes, I think this is a really good question. ¯_(ツ)_/¯

like image 401
matrixisreal Avatar asked Dec 23 '22 15:12

matrixisreal


2 Answers

Does the Destructor just deallocates the memory or actually deletes the object

A destructor calls the destructors of subobjects (if any), executes the destructor body (if it is defined). It is technically not the destructor that deallocates the memory. The destrcutor can be called without deallocation, and memory can be deallocated without the call to a destructor.

When a dynamic object is deleted with operator delete, the destructor will be called, and then the memory is deallocated. Likewise, when the life time of an automatic variable (such as your n) ends, its destructor is called, and the memory is deallocated.

It is unclear what you mean by "deletes the object". A destructor will never call the delete operator (unless the body of the destructor {,of a sub object} sub object calls delete operator, but then it is not this that is deleted).

If you mean whether destructor destroys the object, then it is the other way 'round: When an object is being destroyed, its destructor will be called.

  1. ... But the pointer points to the same object

The pointer points to where the object was. That object has been destroyed and no longer exists.

... and its member functions are still accessible.

Accessibility of a member function does not depend on what is being pointed. Dereferencing a pointer (including calling a member function) that does not point to an object has undefined behaviour.

Doesn't this mean that the object isn't deleted yet?

No. You can't make conclusions from undefined behaviour.

  1. Does overriding the destructor function ...

This is not overriding. Overriding is a specific language term that involves inheritance and virtual functions.

What you have done is define a destructor.

  1. ... and doing nothing in it (here in ~name()), prevent the object from being deleted?

No. Doing nothing in the body of the destructor is exactly the same what the implicit destructor does (the one that the object had when you left the destructor undefined). It does not "prevent the object form being deleted".

like image 117
eerorika Avatar answered Feb 01 '23 12:02

eerorika


In C++ parlance, two separate concepts are 'object lifetime' and 'storage duration'. A duration is pretty much the same as lifetime, but Standard uses two distinct words here. Storage refers to the physical memory occupied by the object, while object lifetime refers to the time when it is allowed to access the object.

With this in mind, one has two understand that constructor and destructor determine object lifetime - it is not allowed to access the object before constructor was called and after destructor was called, and do not say anything about storage lifetime. It is obvious that storage duration (or lifetime) should not be smaller than object lifetime - once can not access object that has no physical representation - but can be longer than it.

It is easily seen when placement new is used together with explicit destructor call - storage remains available, but the object has gone.

like image 32
SergeyA Avatar answered Feb 01 '23 12:02

SergeyA