Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!fluke!mce
From: mce@tc.fluke.COM (Brian McElhinney)
Newsgroups: comp.lang.c++
Subject: Re: Virtual destructors - why aren't they all?
Message-ID: <11748@fluke.COM>
Date: 16 Oct 89 18:18:46 GMT
References: <10627@csli.Stanford.EDU> <6590296@hplsla.HP.COM>
Sender: news@tc.fluke.COM
Organization: Software of the Mist
Lines: 26

In article <6590296@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes:
>>keith@csli.Stanford.EDU (Keith Nishihara) /  5:55 pm  Oct 10, 1989 /
>>the appropriate behaviour to happen.  Why are not all desctructors
>>virtual?  Is this true in other C++ systems?
>
>Well, one answer is that declaring a function virtual causes both a space
>penalty in an object of that class [said penalty constant as long as one
>or more virtual functions are declared] and also a time penalty in invoking
>that virtual function.

This isn't a requirement of the C++ language definition, is it?  I understood
it to be a result of the cfront implementation (eg, relying on standard C and
its linker).  I would expect more advanced C++ compilers to optimize this case;
if a virtual method is never overloaded, call the method directly.

>This behavior is true of all C++ I have seen.  If you want a function to
>be virtual, declare it virtual.  This requirement also has the advantage of 
>language consistency.

And the disadvantage of requiring the original author to anticipate exactly
which methods I will need to override.  You shouldn't need to change
"resuable" source code in order to reuse it.
 
 
Brian McElhinney		  "Knowledge is soon changed, then lost in the
mce@tc.fluke.com		   mist, an echo half-heard"      --Gene Wolfe