Originally Posted by
Elysia
Yes, I know what they are and everything, and it's exactly as I described. If were create pure virtual functions to make sure a class can't be instaciated, then what's the point of defining them when they're always overriden by derived classes?
The point of defining pure virtual functions is that they can be called, and the C++ standard explicitly allows them to be called. For example;
Code:
class Abstract
{
public:
virtual void f() = 0;
};
void Abstract::f()
{
// perform some default action
}
class Concrete: public Abstract
{
public:
void f();
};
void Concrete::f()
{
Abstract::f();
// do something specific to class Concrete
}
This is actually quite allowable in C++. Yes, it is possible to achieve the same effect by other means, but the point of defining a pure virtual function is to allow explicit or implicit calls of that pure virtual function (calling a pure virtual destructor is an example of an implicit call). The decision to call a (defined) pure virtual function is, in practice, a design trade-off ..... there is no absolute rule that says it is always a good thing or a bad thing to do.
I understand the NEED to do so, but I do not see a need to make a pure virutal destructor since, as you mentioned, they must be defined, but since it's a pure virtual function, it isn't supposed to be called, and thus it doesn't meet the define for my interpretation of a pure virtual function.
And this is where your interpretation is showing you are failing to understand the purpose of pure virtual functions. The purpose of pure virtual functions is to prevent instantiation of a class, and to provide an interface that can be inherited by a derived concrete class while selectively forcing the derived class to override selected functions. It has got nothing to do with preventing that function from being called.
A pure virtual destructor can be used in specific cases where a base class must be abstract (i.e. not instantiable) but it is optional for a derived class to override any supplied virtual function because the base class can provide a sensible default behaviour for every virtual function. For example, some design paradigms specifically require that concrete (i.e. instantiable) classes not be derived from, and there are techniques to enforce that. Such paradigms work will if the concrete classes are derived from multiple abstract classes. An practical application is "mixin" classes, which provide default implementations of virtual functions for use by derived classes through multiple inheritance, but it is inappropriate that the mixin class itself be instantiated.
I'll leave finding more information on mixin classes as an exercise.