Memory of a variable or object automatically terminated of finish at the end of program than why we use destructor?

Recommended Answers

All 4 Replies

Simply put, because you don't always want to wait until the end of the program to free resources that are no longer needed by the application.

For example, if you were to hold on to the memory allocated every single time the program calls a class object, or every time the program performs a calculation, or every time the program performs any operation, then eventually your memory usage for a larger, more complex program, would be off the scale.

What might start off as a few bytes here or a couple of kilobytes there would eventually work into megabytes of unreleased memory resources and slow down the operation of your application. Assuming that the application then continues to run for an indefinite amount of time (For example, I don't always close every browser window in my FireFox application and leave 1 or more windows open for days at a time) then those megabytes of unreleased memory become gigabytes of unreleased memory.

As you can see, if you assume that leaving the memory cleanup to the closing of the application will be sufficient you can cause some rather serious memory usage issues with your application.

Hope that helps :)

Look up the term "memory leak" that will explain why.

C++ doesn't have "garbage collection" like many other languages. That responsibility is left to the programmer. A destructor can be thought of as your garbage bin. They are used mostly for de-allocating dynamically-allocated components of custom object classes.

class nonDynamicExample {
 private:
   int myPrvInt; //a private-access integer
 public:
   nonDynamicExample(): myPrvInt(0) {} //default constructor
   //notice that there is no dynamic allocation

   ~nonDynamicExample() {} //destructor
};

In this example, a destructor isn't really needed, but I have included one for demonstration purposes. If you don't provide one, C++ automatically provides a "default" one.

class dynamicExample {
 private:
   int *myPrvIntPtr; //a private-access pointer to integer
 public:
   nonDynamicExample() { //default constructor
     myPrvIntPtr = new int(0);
     //allocate a new integer, place its address in myPrvIntPtr
   }
   //notice that there is no dynamic allocation

   ~nonDynamicExample() { //destructor
     delete myPrvIntPtr;
     //de-allocate the integer whose address is stored in myPrvIntPtr
   }
};

In this example, a destructor is required to prevent a memory leak. The "default" destructor C++ provides if you don't define one is not sufficient to free the allocated memory. It would only free the pointer, not the integer that it points to. This results in a piece of allocated memory that neither you nor your application have access to any more. These inaccessible chunks of memory can add up to a serious problem in a hurry.

What Lusiphur said is true for freeing or deallocating memory. Most of the time, for small applications that don't run for very long and don't use any OS resources (like threads, external processes, internet connection sockets, etc.) it will work fine without explicitly freeing all allocated memory, but not good coding practice though. But there are problems, such as if you are running an algorithm in a loop and in each iteration, you need an array to work with. If you allocate new memory for the array at the start of every iteration and don't deallocate it at the end of the iteration, you will get an perpetual increase in memory usage (e.g. say you have 1000 iterations and allocate 8000 bytes every time, you will wind up at the end of the algorithm with 8000000 bytes of wasted memory that will remain allocated for the entire time of the process).

It is important to distinguish memory allocation/deallocation from constructors/destructors. When you create an object, first memory gets allocated for the object, then the constructor is called to initialize the memory. At deallocation, the inverse happens, the destructor is called to do some clean up, and then the memory of the object is deallocated.

So, Why do we use destructors?
Well for simple classes where the data members are all simple stuff like primitive values (int, float, char, double, etc.) the destructor does not need to do anything and can be either empty or omitted. BUT, if the class allocates resources for the object, like allocating memory with "new" or setting up OS resources like threads or internet connection sockets, then at destruction time, it is important to clean-up all these resources (calling delete[] on allocated memory or terminating a running thread, or closing an internet connection socket). Otherwise, there are possibly severe problems to come, or the application will leave a trail behind, like a bunch of opened sockets and things like that.

C++ doesn't have "garbage collection" like many other languages. That responsibility is left to the programmer.

However, this is only partially true these days as more recent versions of C++ utilizing the .Net standards do have some automatic "Garbage Collection" available.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.