Why are destructors required in C++?

Question

When a pointer goes out of scope, its memory is freed, so why are destructors created in c++?

Answer 1

If you're asking why C++ classes have destructors, some classes have requirements other than just freeing memory. You may have an object that's allocated a socket connection that needs to be shut down cleanly, for example.

Also, 'unscoping' a pointer does not free the memory that it points to since other pointers may be referencing it.

If you have a pointer on the stack, exiting the function will free the memory used by the pointer but not that memory pointed to by the pointer. There's a subtle bit very important distinction.

Answer 2

When a pointer goes out of scope, the memory taken by the pointer is released. The 4 or 8 bytes (usually) of memory that are taken by the pointer, that is.

The object (or other memory) that the pointer points to is not released when the pointer goes out of scope. You do that by delete'ing the pointer. And that invokes the destructor, if there is any.

Answer 3

When ever there is a pointer(exist as class member),there should be a destructor for that class that should delete the object pointed by the pointer member. If you have smart_pointer in place of pointer in class then there is no need of destructor.

below qn will help u understand better. http://stackoverflow.com/questions/147572/will-the-below-code-cause-memory-leak-in-c

Answer 4

First, you mistakenly state that the memory is freed when the pointer goes out of scope. With raw pointers that is false, the memory is lost, and any resource held by the pointed object with it.

Destructors are a core feature of the language, and the base for the RAII idiom for resource management. Objects acquire resources during construction and releases those same resources in the destructor. It is a simple, controllable and simple approach to resource management. Note here that resource is anything from memory (smart pointers destructors free the memory they control, containers free their internal memory structure) or any other resource (ofstreams release open files, database connections free the sockets).

While with managed languages as C# or Java memory is released automatically by the garbage collector, it is only memory that gets realeased, and the user has the strain of controlling all other resources manually in the place of use.

If you check exception control structures in C#/Java you will notice that there is a finally clause non-existent in C++. The reason is that managed languages must provide the user with a block of code that is guaranteed to be executed as to manually free the resources. The strain of releasing resources is placed in the programmer that uses the libraries.

In C++, using the RAII idiom, each object is responsible for the resources it is holding and must release them during destruction. This implies that if you are using objects in the stack resources will be released without user's interaction. The responsibility for controlling resources is in the class, and the user must not remember to free each resource manually.

Many managed language defendants gladly say that not having to remember when or where to release memory as it will be claimed by the garbage collector is a great advantage, but they won't get into the discussion of how other resources are controlled. Memory management is just a subset of the problem of resource management and the same solution applies. If you hold memory inside smart pointers (std::auto_ptr, boost::shared_ptr, std::tr1::unique_ptr, std::tr1::shared_ptr..., choose the one that fits your use) then memory will be managed for you.

While this post seems to have disgressed from the original question of destructors, it is really very closely related. All resource control must be performed in destructors, that is how smart pointers work: when the stack allocated smart pointer goes out of scope the destructor is called and it checks whether the heap (new) allocated memory must be released and if so, delete is called. But then again, this is just a subset of the more general problem.

Answer 5

If you're writing good C++ then you should have very few destructors (in fact I think "few destructors" is a good metric for C++ code quality).

A couple of exceptions I can think of are:

a) When you're working with things which don't destruct themselves, eg. "FILE*".

b) When you're using the "pimpl" idiom (google for "pimpl idiom").

nb. Classes like std::auto_ptr and std::vector will fall into category (a) because at some point they need a C-style pointer to memory.