Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!samsung!spool.mu.edu!snorkelwacker.mit.edu!hsdndev!husc6!ngo
From: ngo@tammy.harvard.edu (Tom Ngo)
Newsgroups: comp.std.c++
Subject: ~virtual (followup to ~const proposal 1.6)
Message-ID: <NGO.91Mar2014617@tammy.harvard.edu>
Date: 2 Mar 91 06:46:17 GMT
Sender: news@husc6.harvard.edu
Distribution: comp
Organization: Harvard Chemistry Department
Lines: 38


Jim Adcock <jimad@microsoft.UUCP> wrote:

jimad> Regards ~virtual:
jimad> 
jimad> Also note, under today's system, where a derived class cannot
jimad> explicitly declare a method ~virtual, the possibility exists
jimad> for a base class programmer to "hijack" a private derived class
jimad> method by declaring it public virtual in the base class. [...]

Excellent point.  This has happened to me more than once, particularly
with the very common virtual function names Draw() and Update()!

The opposite thing has also happened to me:  in a derived class I have
meant for a function to be virtual, but because of a minor difference
in declaration the method in the derived class has created a new vtbl
entry instead of filling in one declared in its base class.  For
example: 

    class Base {
        virtual double foo();
    };
    class Derived {
        virtual double foo() const;
    };

Could once think of some protection against this sort of error?

I like the idea of using ~virtual to protect against the first kind of
error.  These semantics FEEL like those of ~const, even though the
parallel is not perfect (~virtual is a property of a method, whereas
the effects of ~const must be determined separately for each object of
a class).

--
  Tom Ngo
  ngo@harvard.harvard.edu
  617/495-1768 lab number, leave message