Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!rice!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: <11858@fluke.COM>
Date: 20 Oct 89 23:38:10 GMT
References: <10627@csli.Stanford.EDU> <6590296@hplsla.HP.COM> <11748@fluke.COM> <DML.89Oct17135223@bloch.esl.com>
Sender: news@tc.fluke.COM
Organization: Software of the Mist
Lines: 34

In article <DML.89Oct17135223@bloch.esl.com> dml@esl.com (Denis Lynch) writes:
>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.

Actually, I do expect that I will commonly have access to all sources (but
then I work for a medium sized company that can afford it).  You are right in
that there will be exceptions, and the compiler/linker have to handle it.  I
don't see it being a very difficult problem (as long as we are taling about a
"true" C++ compiler/linker, instead of being limited to what C can do).

>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.

And take a performance hit (that's what started this thread of discussion).

>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?

The idea is that, for any public routine, the person *using* the code should
make the decision, not the original author.  C++ takes just the opposite stand.
I am sensitive to the reasons why, but I still feel it is a wart in C++.
 
 
Brian McElhinney		  "Knowledge is soon changed, then lost in the
mce@tc.fluke.com		   mist, an echo half-heard"      --Gene Wolfe