Doesn't putting a "virtual destructor inside an interface" make it, by definition, not an interface anymore?

Question

So here is the box I am in. I want to understand why it is important to have a "virtual destructor inside your interface class". You will see why that stuff is in quotes if you can hang to the end... I also want to get all the vocabulary absolutely correct. Here is where I am at with the process so far:

1. Sometimes you have base classes, sometimes you have derived classes which inherit from base classes.

2. If you have a base-pointer that finds itself pointing to a derived-object, and further you want a member function call made from that base-pointer-pointing-to-a-derived-object to behave as if it had actually been called from the derived object, then the member function you call had better be declared virtual in the base class.

3. An interface is any class with only pure virtual functions. If you derive a new class from this interface class and implement all the pure virtual functions, then you can finally create an instance of the derived class.

4. You can never have an instance of an interface class, BUT you can have an instance of a pointer-to-interface-class.

5. In the case where you have a pointer-to-interface-class that actually points to an object of the derived class (actually, I guess it would always have to if #4 is correct), and if you decide to delete that object through your pointer, then if you don't have a "virtual destructor inside your interface class", your intention to destroy the derived object will only be executed as a call to destroy the base object (i.e. the interface class) and since there is no virtual destructor, things won't ever get to the point where the destructor for the derived object is actually called -- thus causing memory leaks.

Phew. Okay, if that sounds right, onto my question. Is it enough just to declare a virtual destructor inside your interface like this:

virtual ~iFace(); 

That looks wrong to me... so what happens if you make the destructor pure virtual like this:

virtual ~iFace() = 0; 

Since they are just declarations, do either of these count for being a "virtual destructor inside your interface class"? Can you even have a declared but un-defined destructor? Only if it is pure virtual I would guess...

Anyway, so getting back to the title question... I really am going as fast as I can... Here is the money shot... If your "virtual destructor inside your interface class" requires at least an empty definition like this:

virtual ~iFace() {}; 

Then that member function is not pure virtual (can't be because you gave it a definition) and therefore your class is no longer an interface (it does not only contain pure virtual member functions).

This would imply that if you define a virtual destructor for your interface, then you no longer have an interface (but just some abstract base class). Is this just an abuse of language? Do I understand what is going on?

note: All this came from asking myself "What is an interface?" and then reading this question's answers: How do you declare an interface in C++?

Hope that wasn't too long a walk for too short a ride, but I am determined to completely understand these concepts and their associated vocabulary.

Answer 1

Why Abstract class destructor should be virtual and have a definition?

Calling delete on a polymorphic Base class pointer pointing to a Derived class object & the Base class not having a virtual destructor causes an Undefined Behavior.

So you do need to declare the destructor of the polymorphic Base class as virtual. Once you declare your destructor explicitly virtual, you do need to provide a definition for it. This is because the compiler by default generates(defines) a destructor for every class but if you explicitly declare the destructor then the compiler does not do so and leaves it for you to provide a definition for your own destuctor. It makes sense because the compiler sees explicit declaration as an indication that you want to do some non trivial operations(even if you are not in need of doing so) in the destructor and it provides you the opportunity to do so by forcing you to give the definition.

---

Myth 1:
There is something called an Interface in C++.

NO
C++ as a language does not provide an Interface What you refer to as Interface is called an Abstract class in C++. Abstract Classes are used to simulate the behavior of Interface in C++.

What is an Abstract class?
By definition an abstract class should have at least one pure virtual function.

---

Myth 2:
All functions inside Abstract class need to be pure virtual.

NO
Abstract classes do not require all functions inside them to be pure virtual. An object of an Abstract cannot be created if it has at least one pure virtual function. Though, as you correctly mentioned you can create pointers to it.

---

Myth 3:
Pure virtual functions cannot have a definition.

NO
It is perfectly valid for Pure virtual functions to have a definition.

---

Why would I ever need a Pure virtual function with definition?
Code speaks louder then words, So here is a simple example:
Warning: Uncompiled code only for demonstration

class IMyInterface {     int i;     int j;     public:         virtual void SetMembers(int ii, int jj)=0; };  /*The pure virtual function cannot be inline in the class definition*/ /*So this has to be here*/ void IMyInterface::SetMembers(int ii, int jj) {     i = ii;     j = jj; }  class Myclass: public IMyInterface {     int k;     int l;     public:         virtual void SetMembers(int ll, int m, int a, int b)         {              k = ll;              l = m;              IMyInterface::SetMembers(a,b);          } };  int main() {      MyClass obj;     obj.SetMembers(10,20,30,40);     return 0; } 

Answer 2

C++ doesn't have a native interface entity. Interfaces are implemented as regular classes.

What makes a class an interface in C++ is, therefore, not something that has universal agreement. Personally I consider a class to be an interface if it has no data members, no user-declared constructors and all of its functions are pure virtual - with the possible exception of its destructor - and all of its base classes, if any, are also interfaces. If a class doesn't quite fit all of these properties I might refer to it as a "fat" interface (generally not a compliment!).

If you want to delete dynamically allocated polymorphic classes through a pointer to a base class (such as an "interface" class) then the base class destructor must be declared virtual. This means that it must be a user-declared destructor and not an implicitly declared destructor which would be non-virtual.

Once you declare a destructor explicitly, you must provide an implementation for it. (A base class destructor will always be used when you destroy an instance of any class derived from it whether or not the base class destructor is declared pure virtual, virtual or non-virtual.) This is purely an C++ language implementation detail. It doesn't mean that your base class is any less of an "interface", if you have an interface class then it is very likely that the implementation of the destructor will be empty in any case - you have no members or base classes with members to worry about.

If your interface has at least some pure virtual functions then there is no real merit to marking the destructor as pure, your interface class is already an abstract class. Derived class destructors don't technically override base class destructors so you're not requiring derived classes to provide user-declared destructors or anything like that.

Declaring a destructor as a pure virtual also robs you of the ability to provide the definition of the destructor inline in the class definition, although this is a minor detail.