🚀 go-pugleaf

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