What Is the Use of Having Destructor as Private

What is the use of having destructor as private?

Basically, any time you want some other class to be responsible for the life cycle of your class' objects, or you have reason to prevent the destruction of an object, you can make the destructor private.

For instance, if you're doing some sort of reference counting thing, you can have the object (or manager that has been "friend"ed) responsible for counting the number of references to itself and delete it when the number hits zero. A private dtor would prevent anybody else from deleting it when there were still references to it.

For another instance, what if you have an object that has a manager (or itself) that may destroy it or may decline to destroy it depending on other conditions in the program, such as a database connection being open or a file being written. You could have a "request_delete" method in the class or the manager that will check that condition and it will either delete or decline, and return a status telling you what it did. That's far more flexible that just calling "delete".

Protected vs Private Destructor

Taken from here:

If the constructor/destructor is declared as private, then the class cannot be instantiated.

This is true, however it can be instantiated from another method in the class. Similarly, if the destructor is private, then the object can only be deleted from inside the class as well. Also, it prevents the class from being inherited (or at least, prevent the inherited class from being instantiated/destroyed at all).

Is it ok to declare destructor as private?

In php the __destruct magic method must be public. The method will automatically be called externally to the instance. Declaring __destruct as protected or private will result in a warning and the magic method will not be called.

There's no symmetry necessary, as you should never explicitly call __destruct.

Why private destructor in a Singleton class?

Making the destructor private potentially prevents someone from trying to call delete on a pointer to the singleton.

auto& singleton = CMySingleton::Instance();
auto pointer_to_singleton = &singleton;
delete pointer_to_singleton;  // Bad!

Disabling the assignment operator prevents harmless but nonsensical self-assignment. See this answer. If someone is doing this, chances are, it was a mistake so you might as well prevent it.

Private Derived Destructor

Because destructors are called in reversed order of constructors and virtual destructor will always be called.

private has nothing to do if a virtual function is going to be called.

As I pointed here out:

Why would a virtual function be private?

ISO C++ 1998 Standard onwards explicitly states:

§10.3 [...] Access control (clause 11) is not considered in determining overriding.

---

A bit philosophical offtopic:

Going further this is what STL does for iostreams: Definition of Non-Virtual Interface, i.e. all public functions (with exception of destructors) are non-virtual and all virtual functions are either protected or private. Public functions call virtual protected or private ones. This gives a very clear entry point into the entire hierarchy.

Destructing objects with private destructors

You could use SFINAE:

template <typename T>
auto destruct(T* t) -> decltype(t->~T()) { t->~T(); }

auto destruct(void*) { /*  throw, exit, ... */ }

Demo

C++ Destructor: cannot access private member declared in class

If the constructor/destructor is declared as private, then the class cannot be instantiated. If the destructor is private, then the object can only be deleted from inside the class as well. Also, it prevents the class from being inherited (or at least, prevent the inherited class from being instantiated/destroyed at all).

The use of having destructor as private:

Any time you want some other class to be responsible for the life cycle of your class' objects, or you have reason to prevent the destruction of an object, you can make the destructor private.

For instance, if you're doing some sort of reference counting thing, you can have the object (or manager that has been "friend"ed) responsible for counting the number of references to itself and delete it when the number hits zero. A private dtor would prevent anybody else from deleting it when there were still references to it.

For another instance, what if you have an object that has a manager (or itself) that may destroy it or may decline to destroy it depending on other conditions in the program, such as a database connection being open or a file being written. You could have a "request_delete" method in the class or the manager that will check that condition and it will either delete or decline, and return a status telling you what it did. That's far more flexible that just calling "delete".

So, I suggest that you could declare ~Movie(); as public. Then, the problem will be solved.

---

Related Topics