Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > virtual destructor Vs virtual method

Reply
Thread Tools

virtual destructor Vs virtual method

 
 
Calvin Lai
Guest
Posts: n/a
 
      12-17-2003
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.


 
Reply With Quote
 
 
 
 
jeffc
Guest
Posts: n/a
 
      12-17-2003

"Calvin Lai" <(E-Mail Removed)> wrote in message
newsA3Eb.72661$(E-Mail Removed) ble.rogers.com...
> 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.


 
Reply With Quote
 
 
 
 
Calvin Lai
Guest
Posts: n/a
 
      12-17-2003
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


"jeffc" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> "Calvin Lai" <(E-Mail Removed)> wrote in message
> newsA3Eb.72661$(E-Mail Removed) ble.rogers.com...
> > 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.
>
>



 
Reply With Quote
 
David White
Guest
Posts: n/a
 
      12-17-2003
"Calvin Lai" <(E-Mail Removed)> wrote in message
news:994Eb.72669$(E-Mail Removed) ble.rogers.com...
> 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



 
Reply With Quote
 
jeffc
Guest
Posts: n/a
 
      12-17-2003

"Calvin Lai" <(E-Mail Removed)> wrote in message
news:994Eb.72669$(E-Mail Removed) ble.rogers.com...
> 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.


 
Reply With Quote
 
Kevin Saff
Guest
Posts: n/a
 
      12-17-2003
"Calvin Lai" <(E-Mail Removed)> wrote in message
news:994Eb.72669$(E-Mail Removed) ble.rogers.com...
> 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
--
KCS


 
Reply With Quote
 
Kevin Saff
Guest
Posts: n/a
 
      12-17-2003
"Kevin Saff" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Calvin Lai" <(E-Mail Removed)> wrote in message
> news:994Eb.72669$(E-Mail Removed) ble.rogers.com...
> > 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.

--
KCS


 
Reply With Quote
 
Calvin Lai
Guest
Posts: n/a
 
      12-18-2003
Thanks all for your comments. They are very helpful. I got it now.


"Calvin Lai" <(E-Mail Removed)> wrote in message
news:994Eb.72669$(E-Mail Removed) ble.rogers.com...
> 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
>
>
> "jeffc" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> >
> > "Calvin Lai" <(E-Mail Removed)> wrote in message
> > newsA3Eb.72661$(E-Mail Removed) ble.rogers.com...
> > > 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.
> >
> >

>
>



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
newbie -- smart pointer destructor called without destructor everbeing called Jimmy Hartzell C++ 2 05-20-2008 02:20 AM
newbie -- smart pointer destructor called without destructor everbeing called Jimmy Hartzell C++ 0 05-19-2008 07:05 PM
compiler generated destructor vs class implemented destructor arun C++ 2 06-13-2006 05:43 AM
Explicit destructor calls from inside base class destructor frs C++ 20 09-21-2005 09:22 AM
Virtual destructor for virtual base class? Chunhui Han C++ 2 06-24-2004 10:13 AM



Advertisments