Question:
If the destructor is called from a new’ed object (a->A::~A()), is the object’s instance deleted?
Answer:
No. A destructor is a special member function of a class that is implicitly called by the compiler as a result of an object (instance of a class) being destroyed. Explicitly invoking a destructor is no different than invoking a normal member function. It would, in effect, cause whatever behavior defined within that function block to be performed. In general, destructors usually clean up memory allocated on the heap by constructors. For example:
class Foo{public: // Constructor Foo( ) { m_pBar =3D new Bar; } // Destructor ~Foo( ) { delete m_pBar; }private: Bar* m_pBar;};You could, in a block of code, construct an object of type Foo that in turn will call its constructor which contains a data member m_pBar of type Bar that allocates an instance on the heap.{Foo myFoo;?}When program execution falls outside that block of code, myFoo will be destroyed, causing its destructor to be called prior to the destruction of the myFoo object, which is exactly what we want to happen. As you can see, because data members of the class are allocated on the heap for each object instantiation, then they must be removed upon destruction of each object. Now if you were to call the destructor explicitly, it would do whatever is defined in the destructor function block, which in this case is to remove the memory allocated on the heap by the constructor. Then later, when myFoo falls out of scope (when program execution falls out of the specific block of code), myFoo is destroyed by the compiler causing its destructor to be called, but you’ve explicitly called it before; therefore, the destructor will attempt to remove memory allocated from an invalid location on the heap, thus normally resulting in a program assertion.Having said that, in most cases you should never explicitly invoke a destructor. You should only explicitly destroy an object if you explicitly created an object on the heap. For example:
Foo myFoo =3D new Foo; // create myFoo object of type Foo on the heap// Use myFoo ?myFoo.DoSomething(?);?// When finished with myFoo, delete it from the heap as a result, causing its destructor to be called.delete myFoo;If you constructed an object on the stack, you don’t have to do anything. The compiler automatically destroys it when it falls out of scope; hence, its destructor gets called.
Since I did say “in most cases,” that menas there are exceptions. The one major exception is in the case of multiple inheritance, where it could be a question of ambiguity, therefore requiring you to explicitly call destructors of a given class’ ancestors. But that is a topic for another question.
Sidebar: If you do not release the memory allocated on the heap, it cannot be used by any other resource during the lifetime of the given process instance; hence, you would have what is known as a memory leak. These leaks are probably the biggest problem for C++ programmers because they are not easily detectable. If you don’t have advance debugging tools such as Purify or Bounds Checker to indicate where a memory leak exists, you could spend many wasted hours or even days trying to track it down. Following the principle of allocating memory on the heap in the class constructor, and freeing it in the class destructor, will prevent these problems.
