Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!ccu.umanitoba.ca!herald.usask.ca!alberta!ubc-cs!uw-beaver!zephyr.ens.tek.com!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.std.c++
Subject: Re: Responses to ~const 1.6:  Possible generalizations of ~const
Message-ID: <70875@microsoft.UUCP>
Date: 25 Feb 91 20:06:41 GMT
References: <NGO.91Feb19114034@tammy.harvard.edu>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Distribution: comp
Organization: Microsoft Corp., Redmond WA
Lines: 58

In article <NGO.91Feb19114034@tammy.harvard.edu> ngo@tammy.harvard.edu (Tom Ngo) writes:
|   * ~virtual is the one I am least convinced about.  Clearly it does
|     nothing to a method which is not already in the vtable of any
|     base class.  So we are left with the following semantics.
|     Following ARM 10.2,
|     
|         If a class "base" contains a virtual function vf(), and a
|         class "derived" derived from it also contains a function vf
|         of the same type, then a call of vf for an object of class
|         "derived" invokes derived::vf() (even if the access is
|         through a pointer or reference to "base").  The derived class
|         function is said to override the base class function....
|         
|         ...the interpretation of the call of a virtual function
|         depends on the type of the object for which it is called,
|         whereas the interpretation of a call of a nonvirtual member
|         function depends only on the type of the pointer or reference
|         denoting that object....
|         
|         ...An overriding function is itself considered virtual UNLESS
|         it is declared ~virtual.
|     
|     I am uncomfortable with the fact that someone writing a function
|     that takes pointers to "base" cannot know whether calls to vf()
|     are really virtual for all derived classes, without looking at
|     all of their declarations.
|     
|     I am still interested in hearing about potential uses for ~virtual.

An alternative interpretation of ~virtual that might make sense is
that a ~virtual in a derived class that conflicts with a virtual in
a public? base class is an error.  In my experience, more compulsive C++
programmers desire to explicitly state whether a function in a derived
class is virtual or not -- they desire this for "documentary" purposes.  Today, 
they do this something like:

#define non_virtual /* nothing */

then mark all their routines either virtual or non-virtual:

class derived : public base
{
....
public:
	non_virtual int   doX();
	virtual     void  doY();
	non_virtual void  doZ();
....
};

The problem with this approach is that it requires the class deriver 
to correctly mark whether a particular function is indeed virtual or 
not -- a function incorrectly marked non-virtual will not be diagnosed.

If ~virtual were explicitly included in the language, then compilers 
could diagnose those situations where assuptions about non-virtualness
are stated incorrectly in derived classes.  Today, such a check simply
cannot exist.