Inapoi
Inainte
Cuprins
Pure virtual destructors
While
pure
virtual destructors are legal in Standard C++, there is an added constraint when
using them: you must provide a function body for the pure virtual destructor.
This seems counterintuitive; how can a virtual function be “pure”
if it needs a function body? But if you keep in mind that constructors and
destructors are special operations it makes more sense, especially if you
remember that all destructors in a class hierarchy are always called. If you
could leave off the definition for a pure virtual destructor, what
function body would be called during destruction? Thus, it’s absolutely
necessary that the compiler and linker enforce the existence of a function body
for a pure virtual destructor.
If it’s pure, but it has to have a
function body, what’s the value of it? The only difference you’ll
see between the pure and non-pure virtual destructor is that the pure virtual
destructor does cause the base class to be abstract, so you cannot create an
object of the base class (although this would also be true if any other member
function of the base class were pure virtual).
Things are a bit confusing, however, when
you inherit a class from one that contains a pure virtual destructor. Unlike
every other pure virtual function, you are not required to provide a
definition of a pure virtual destructor in the derived class. The fact that the
following compiles and links is the proof:
//: C15:UnAbstract.cpp
// Pure virtual destructors
// seem to behave strangely
class AbstractBase {
public:
virtual ~AbstractBase() = 0;
};
AbstractBase::~AbstractBase() {}
class Derived : public AbstractBase {};
// No overriding of destructor necessary?
int main() { Derived d; } ///:~
Normally, a pure virtual function in a
base class would cause the derived class to be abstract unless it (and all other
pure virtual functions) is given a definition. But here, this seems not to be
the case. However, remember that the compiler automatically creates a
destructor definition for every class if you don’t create one.
That’s what’s happening here – the base class destructor is
being quietly overridden, and thus the definition is being provided by the
compiler and Derived is not actually abstract.
This brings up an interesting question:
What is the point of a pure virtual destructor? Unlike an ordinary pure virtual
function, you must give it a function body. In a derived class, you
aren’t forced to provide a definition since the compiler synthesizes the
destructor for you. So what’s the difference between a regular virtual
destructor and a pure virtual destructor?
The only distinction occurs when you have
a class that only has a single pure virtual function: the destructor. In this
case, the only effect of the purity of the destructor is to prevent the
instantiation of the base class. If there were any other pure virtual functions,
they would prevent the instantiation of the base class, but if there are no
others, then the pure virtual destructor will do it. So, while the addition of a
virtual destructor is essential, whether it’s pure or not isn’t so
important.
When you run the following example, you
can see that the pure virtual function body is called after the derived class
version, just as with any other destructor:
//: C15:PureVirtualDestructors.cpp
// Pure virtual destructors
// require a function body
#include <iostream>
using namespace std;
class Pet {
public:
virtual ~Pet() = 0;
};
Pet::~Pet() {
cout << "~Pet()" << endl;
}
class Dog : public Pet {
public:
~Dog() {
cout << "~Dog()" << endl;
}
};
int main() {
Pet* p = new Dog; // Upcast
delete p; // Virtual destructor call
} ///:~
As a guideline, any time you have a
virtual function in a class, you should immediately add a virtual destructor
(even if it does nothing). This way, you ensure against any surprises
later.
Virtuals in
destructors
There’s something that happens
during destruction that you might not immediately expect. If you’re inside
an ordinary member function and you call a virtual function, that function is
called using the late-binding mechanism. This is not true with destructors,
virtual or not. Inside a destructor, only the “local” version of the
member function is called; the virtual mechanism is ignored.
//: C15:VirtualsInDestructors.cpp
// Virtual calls inside destructors
#include <iostream>
using namespace std;
class Base {
public:
virtual ~Base() {
cout << "Base1()\n";
f();
}
virtual void f() { cout << "Base::f()\n"; }
};
class Derived : public Base {
public:
~Derived() { cout << "~Derived()\n"; }
void f() { cout << "Derived::f()\n"; }
};
int main() {
Base* bp = new Derived; // Upcast
delete bp;
} ///:~
During the destructor call,
Derived::f( ) is not called, even though f( ) is
virtual.
Why is this? Suppose the virtual
mechanism were used inside the destructor. Then it would be possible for
the virtual call to resolve to a function that was “farther out”
(more derived) on the inheritance hierarchy than the current destructor. But
destructors are called from the “outside in” (from the most-derived
destructor down to the base destructor), so the actual function called would
rely on portions of an object that have already been destroyed! Instead,
the compiler resolves the calls at compile-time and calls only the
“local” version of the function. Notice that the same is true for
the constructor (as described earlier), but in the constructor’s case the
type information wasn’t available, whereas in the destructor the
information (that is, the VPTR) is there, but is isn’t
reliable.
Creating an object-based
hierarchy
An issue that has been recurring
throughout this book during the demonstration of the container classes
Stack and Stash is the “ownership problem.” The
“owner” refers to who or what is responsible for calling delete
for objects that have been created dynamically (using new). The
problem when using containers is that they need to be flexible enough to hold
different types of objects. To do this, the containers have held void
pointers and so they haven’t known the type of object they’ve held.
Deleting a void pointer doesn’t call the destructor, so the
container couldn’t be responsible for cleaning up its
objects.
One solution was presented in the example
C14:InheritStack.cpp, in which the Stack was inherited into a new
class that accepted and produced only string pointers. Since it knew that
it could hold only pointers to string objects, it could properly delete
them. This was a nice solution, but it requires you to inherit a new container
class for each type that you want to hold in the container. (Although this seems
tedious now, it will actually work quite well in Chapter 16, when templates are
introduced.)
The problem is that you want the
container to hold more than one type, but you don’t want to use
void pointers. Another solution is to use polymorphism by forcing all the
objects held in the container to be inherited from the same base class. That is,
the container holds the objects of the base class, and then you can call virtual
functions – in particular, you can call virtual destructors to solve the
ownership problem.
This
solution uses what is referred to as a singly-rooted hierarchy or an
object-based hierarchy (because the root class of the hierarchy is
usually named “Object”). It turns out that there are many other
benefits to using a singly-rooted hierarchy; in fact, every other
object-oriented language but C++ enforces the use of such a hierarchy –
when you create a class, you are automatically inheriting it directly or
indirectly from a common base class, a base class that was established by the
creators of the language. In C++, it was thought that the enforced use of this
common base class would cause too much overhead, so it was left out. However,
you can choose to use a common base class in your own projects, and this subject
will be examined further in Volume 2 of this book.
To solve the ownership problem, we can
create an extremely simple Object for the base class, which contains only
a virtual destructor. The Stack can then hold classes inherited from
Object:
//: C15:OStack.h
// Using a singly-rooted hierarchy
#ifndef OSTACK_H
#define OSTACK_H
class Object {
public:
virtual ~Object() = 0;
};
// Required definition:
inline Object::~Object() {}
class Stack {
struct Link {
Object* data;
Link* next;
Link(Object* dat, Link* nxt) :
data(dat), next(nxt) {}
}* head;
public:
Stack() : head(0) {}
~Stack(){
while(head)
delete pop();
}
void push(Object* dat) {
head = new Link(dat, head);
}
Object* peek() const {
return head ? head->data : 0;
}
Object* pop() {
if(head == 0) return 0;
Object* result = head->data;
Link* oldHead = head;
head = head->next;
delete oldHead;
return result;
}
};
#endif // OSTACK_H ///:~
To simplify things by keeping everything
in the header file, the (required) definition for the pure virtual destructor is
inlined into the header file, and pop( ) (which might be considered
too large for inlining) is also inlined.
Link
objects now hold pointers to Object rather than void pointers, and
the Stack will only accept and return Object pointers. Now
Stack is much more flexible, since it will hold lots of different types
but will also destroy any objects that are left on the Stack. The new
limitation (which will be finally removed when templates are applied to the
problem in Chapter 16) is that anything that is placed on the Stack must
be inherited from Object. That’s fine if you are starting your
class from scratch, but what if you already have a class such as string
that you want to be able to put onto the Stack? In this case, the new
class must be both a string and an Object, which means it must be
inherited from both classes. This is called multiple inheritance and it
is the subject of an entire chapter in Volume 2 of this book (downloadable from
www.BruceEckel.com). When you read that chapter, you’ll see that
multiple inheritance can be fraught with complexity, and is a feature you should
use sparingly. In this situation, however, everything is simple enough that we
don’t trip across any multiple inheritance pitfalls:
//: C15:OStackTest.cpp
//{T} OStackTest.cpp
#include "OStack.h"
#include "../require.h"
#include <fstream>
#include <iostream>
#include <string>
using namespace std;
// Use multiple inheritance. We want
// both a string and an Object:
class MyString: public string, public Object {
public:
~MyString() {
cout << "deleting string: " << *this << endl;
}
MyString(string s) : string(s) {}
};
int main(int argc, char* argv[]) {
requireArgs(argc, 1); // File name is argument
ifstream in(argv[1]);
assure(in, argv[1]);
Stack textlines;
string line;
// Read file and store lines in the stack:
while(getline(in, line))
textlines.push(new MyString(line));
// Pop some lines from the stack:
MyString* s;
for(int i = 0; i < 10; i++) {
if((s=(MyString*)textlines.pop())==0) break;
cout << *s << endl;
delete s;
}
cout << "Letting the destructor do the rest:"
<< endl;
} ///:~
Although this is similar to the previous
version of the test program for Stack, you’ll notice that only 10
elements are popped from the stack, which means there are probably some objects
remaining. Because the Stack knows that it holds Objects, the
destructor can properly clean things up, and you’ll see this in the output
of the program, since the MyString objects print messages as they are
destroyed.
Creating containers that hold
Objects is not an unreasonable approach – if you have a
singly-rooted hierarchy (enforced either by the language or by the requirement
that every class inherit from Object). In that case, everything is
guaranteed to be an Object and so it’s not very complicated to use
the containers. In C++, however, you cannot expect this from every class, so
you’re bound to trip over multiple inheritance if you take this approach.
You’ll see in Chapter 16 that templates solve the problem in a much
simpler and more elegant
fashion.
 |
|
|
