Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!apple!excelan!leadsv!esl!esl.ESL.COM!dml
From: dml@esl.com (Denis Lynch)
Newsgroups: comp.lang.c++
Subject: Re: Virtual destructors - why aren't they all?
Message-ID: <DML.89Oct17135223@bloch.esl.com>
Date: 17 Oct 89 20:52:23 GMT
References: <10627@csli.Stanford.EDU> <6590296@hplsla.HP.COM> <11748@fluke.COM>
Sender: news@esl.ESL.COM
Organization: ESL Inc., Sunnyvale, CA
Lines: 46
In-reply-to: mce@tc.fluke.COM's message of 16 Oct 89 18:18:46 GMT

In article <11748@fluke.COM> mce@tc.fluke.COM (Brian McElhinney) writes:
   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.

I find this an interesting juxtaposition of arguments, Brian.

First, the "smart compiler" problem. Since reusable code is likely to go in a
library, the compiler can't possibly tell whether an operator is overloaded.
Unless you expect to have access to the source code for all your libraries, which
the library vendors aren't likely to be excited about.

Second, the "anticipation" problem. Here, you must be arguing that you want
*all* member functions to be virtual, i.e. overridable. If that's what you
want, you don't need a smart compiler or a language change, just declare all
your functions virtual.

The current language gives you the option of writing member functions that you
*know* will not be overriden, and others that may be. This is a reasonable
extension of the public/private/protected distinctions: you can have code
that is guaranteed to call the function you wrote, never a client's "better
idea."

Or did I miss something?

Denis Lynch
dml@esl.com