Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!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: <70876@microsoft.UUCP> Date: 25 Feb 91 20:23:31 GMT References: Reply-To: jimad@microsoft.UUCP (Jim ADCOCK) Distribution: comp Organization: Microsoft Corp., Redmond WA Lines: 19 Regards ~virtual: Also note, under today's system, where a derived class cannot explicitly declare a method ~virtual, the possibility exists for a base class programmer to "hijack" a private derived class method by declaring it public virtual in the base class. For example, when modifying a base class, the base class programmer might accidentally choose a virtual function name used privately non-virtually in a derived class. The effect would be that what was intended to be a private non-virtual method in the derived class is accidentally promoted, without warning, to become one flavor of a public virtual method of the base class. If the derived class programmer could explicitly mark private non-virtual methods with ~virtual, then attempts to make such virtual in the base class would cause an error. I claim this is how it should be. Base classes should be able to protect and defend methods declared in the base class. Derived classes should be able to protect and defend methods declared in the derived class. If the two classes refuse to agree, a compile-time error should result.