virtual destructor Vs virtual method

[Calvin Lai]

Hi all,

I have a simple question. If I have a ClassA as base class, and ClassB
derive from it. There is a virtual function foo() in ClassA, and in Class B,
I defined a function called foo() as well (w/ or w/o declaring it as virtual
doesn't matter since the virtual is inhered, right?). Both of them have a
virtual destructor.

Now, here is the part of the code:

ClassA::foo()
{
cout << "In class A"
}

ClassB::foo()
{
cout << "In class B"
}

ClassA::~ClassA()
{
cout << "destroying A"
}

ClassB::~ClassB()
{
cout << "destroying A"
}

When deleting objectB (from ClassB), both destructors are called. However,
when calling objectB's foo, only the classB's foo is called. Why is that?
Thanks for all your help.

 

[jeffc]

Hi all,

I have a simple question. If I have a ClassA as base class, and ClassB
derive from it. There is a virtual function foo() in ClassA, and in Class B,
I defined a function called foo() as well (w/ or w/o declaring it as virtual
doesn't matter since the virtual is inhered, right?).
Correct.

Both of them have a
virtual destructor.

Now, here is the part of the code:

ClassA::foo()
{
cout << "In class A"
}

ClassB::foo()
{
cout << "In class B"
}

ClassA::~ClassA()
{
cout << "destroying A"
}

ClassB::~ClassB()
{
cout << "destroying A"
}

When deleting objectB (from ClassB), both destructors are called. However,
when calling objectB's foo, only the classB's foo is called. Why is that?

Because an object of type ClassB is actually composed of parts of both
ClassA and ClassB. Let's say in ClassA there were a file, and in ClassB
there was also a file. In an object of type ClassA, there will be 1 file.
In an object of type ClassB, there will be 2 files. When you delete an
object of ClassB, don't you want to make sure that both files are closed?
The closing of the file in ClassA should logically be closed in the
destructor for ClassA. On the other hand, functions aren't the same as
storage. Functions have to do with behavior, and if you want the behavior
of ClassB to be different from that of ClassA, then there's no reason to
call ClassA's function. You could though. In ClassB::foo(), you could make
a call to ClassA::foo(). Then it would work the same way as the destructor
calls.

 

[Calvin Lai]

Thanks Jeff. However, is this a logical reasoning of why this is happening
by design, or there is other behind the door arguments for it?

Calvin

 

[David White]

Thanks Jeff. However, is this a logical reasoning of why this is happening
by design, or there is other behind the door arguments for it?

I'm not sure what you mean. A destructor isn't a normal function. It is
there to do necessary cleanup, so a derived class has no business preventing
its base class's destructor executing. Therefore, it executes automatically.
An ordinary member function, OTOH, is a different matter. A derived class is
there to alter or extend the behaviour of its base class, so it sometimes
is, and sometimes isn't, appropriate for a virtual function override to call
its base class version. For example, a virtual Clone function returns a new
copy of an object. Obviously, only one copy should be made and it should be
of the most derived class, so it would make no sense at all for any virtual
Clone function in a class hierarchy to call its base-class version.

Futhermore, even when a virtual function does call its base class version,
in some cases it should be called first, in others last, and in still others
somewhere in the middle of the derived class override. It all depends on
just how the derived class wants to modify/extend the base class's
behaviour.

For all these reasons, calling the base class version of an ordinary virtual
function from an override is left up to the programmer.

DW

 

[jeffc]

Thanks Jeff. However, is this a logical reasoning of why this is happening
by design, or there is other behind the door arguments for it?

I don't understand your question. If you mean why was the language
originally designed this way, Bjarne Stroustrup wrote a book about that.
From an object-oriented design perspective though (which is unrelated to the
C++ language per se), it makes good sense to me.

 

[Kevin Saff]

Thanks Jeff. However, is this a logical reasoning of why this is happening
by design, or there is other behind the door arguments for it?

Calvin

It's by design. Perhaps the following (succint, yet dumb) code example will
help.

/////

#include <iostream>
#include <ostream>

class Base
{
public:
Base()
{
std::cout << "Base: " << foo() << std::endl;
}
virtual int foo() {return 3;}
virtual ~Base()
{
std::cout << "~Base: " << foo() << std::endl;
}
};

class Derived
{
int *x_;
public:
Derived() : x_ (new int (5))
{
std::cout << "Derived: " << foo() << std::endl;
}
int foo() {return *x_;}
~Derived()
{
std::cout << "~Derived: " << foo() << std::endl;
delete x_;
}
};

int main()
{
Derived d;
}

/////

creates output:
Base: 3
Derived: 5
~Derived: 5
~Base: 3


If Base could reach Derived::foo in its destructor, it would try to access
invalid memory. From a design point of view we get much better class
invariants* if we can assume a function will only be called on a constructed
object. Otherwise here we might need to (somehow) check in Derived::foo if
an actual Derived object exists or not - which seems kind of silly.


*: (Invariants are conditions that are always true for an object. An
invariant in Derived above is that x_ always points to a valid int, so we
never need to do the check x_ against NULL. Maintaining good invariants is
key to OO programming, and a motivating reason for data encapsulation.)

HTH

 

[Kevin Saff]

Thanks Jeff. However, is this a logical reasoning of why this is happening
by design, or there is other behind the door arguments for it?

[SNIP]


If Base could reach Derived::foo in its destructor, it would try to access
invalid memory. From a design point of view we get much better class

I totally misunderstood the question. How embarrassing! Guess I'm done for
the day.

 

[Calvin Lai]

Thanks all for your comments. They are very helpful. I got it now.