Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!rutgers!uwm.edu!zaphod.mps.ohio-state.edu!samsung!uunet!rocket!dove
From: dove@rocket.uucp (Webster &)
Newsgroups: comp.std.c++
Subject: Re: Can we allow virtual function member declarations to be inherited?
Message-ID: <DOVE.90Aug5133123@hobbes.uucp>
Date: 5 Aug 90 17:31:23 GMT
References: <DOVE.90Jul31222153@rocket.uucp> <37923@ucbvax.BERKELEY.EDU>
Sender: news@rocket.UUCP
Distribution: comp
Organization: Lockheed Sanders Inc.
Lines: 72
In-reply-to: jbuck@galileo.berkeley.edu's message of 1 Aug 90 22:51:36 GMT

In article <37923@ucbvax.BERKELEY.EDU> jbuck@galileo.berkeley.edu (Joe Buck) writes:

   From: jbuck@galileo.berkeley.edu (Joe Buck)
   Date: 1 Aug 90 22:51:36 GMT

   In article <DOVE.90Jul31222153@rocket.uucp>, dove@rocket.uucp (Webster
   &) writes:
   |> That way a user will write a definition for the body of a derived
   |> class virtual function without declaring it in the derived class
   |> definition.  The derived class declaration element for the virtual
   |> function is then inherited from an ancestral base class and the
   |> inherited declaration and explicit definition MUST MATCH or a compile
   |> time error occurs.

   You've neglected to say what happens if I have

   class Base {
	   ...
	   virtual void foo();
   }

   class Derived : public Base {
	   ...
   }

   and do not define void Derived::foo().  Currently, no problem; Base::foo()
   is used.  Under your system, how can we know this?  Your system seems to
   expect to use a Derived::foo() to be defined.  Won't the linker report
   an undefined symbol?

No, the body of the function member will be inherited just as the
declaration was unless one or the other is overridden in this
derived class.

In essence all I am suggesting is that virtual function member
specifications (inside the class specification) be optionally
inheritable just as body definitions currently are.

If the writer intends to use an inherited virtual function member spec
(my case), they just write the body.  Failure to match the inherited
virtual spec causes a compiler error.

If they want to inherit both the spec and the body (as in your case)
they need only do what you did.

   This is a real issue though; it's one of the things that most frequently
   burns me in C++ development.  That's because the keyword virtual may
   mean two things: define a new virtual function that applies from this
   point in the class hierarchy downwards, OR override the baseclass definition
   of this function, as follows.  There's no way to unambiguously specify
   one or the other.

In the current language there is no need to use the word virtual if
you are overriding the inherited definition only if you are starting a
new virtual at the new level.

Note that once a function/args pair has been spec'd as virtual it
remains virtual for all offspring.  The only thing that redeclaration
of the spec can do for you is change whether the function member is
public (ignoring the fact that you must currently put in the spec
whether you need it or not).

Web
--
Dr. Webster Dove				Dr. Webster Dove
Experimental Computing Systems ('X')		Lockheed Sanders Inc.  
Signal Processing Center of Technology		144 Daniel Webster Hwy.
Lockheed Sanders Inc.				Merrimack, NH.  03054  
						
email: 
	(usenet)	...!uunet!rocket!dove
	(or internet)	<rocket!dove@uunet.uu.net>