Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!wuarchive!decwrl!ucbvax!galileo.berkeley.edu!jbuck
From: jbuck@galileo.berkeley.edu (Joe Buck)
Newsgroups: comp.std.c++
Subject: Re: Can we allow virtual function member declarations to be inherited?
Message-ID: <37923@ucbvax.BERKELEY.EDU>
Date: 1 Aug 90 22:51:36 GMT
References: <DOVE.90Jul31222153@rocket.uucp>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: jbuck@galileo.berkeley.edu (Joe Buck)
Distribution: comp
Lines: 97

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?

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.

An off-the-wall idea I don't expect to be accepted: allow the following
syntax:

class Derived : public Base {
	virtual foo;
}

That's right; omit the types.  This means that class Derived intends to
override all virtual functions of the baseclass that are named foo.
This is analogous to the following existing C++ notation:

class Base {
	...
public:
	int func1(int,char*);
	...
}

class Derived: private Base {
	...
public:
	Base::func1;		// make func1 public for class Derived
	...
}

Here again, you omit the type and arguments to the member function.
If the "virtual foo;" notation is used, it is required that a
void Derived::foo() is defined or you get an undefined symbol.


|> This would be substantially better than the current situation in which
|> given a mistaken difference between the intended base class virtual
|> function calling sequence and the actual derived class calling
|> sequence you just end up with a new virtual function at the level of
|> the derived class with no warning whatever about potential
|> misbehavior.
|> 
|> This is problem with a substantial probability of occurance since I
|> have seen this situation occur independently to two different
|> InterViews users.
|> 
|> This approach will save people who use public libraries from getting
|> shafted when a minor change happens in the calling syntax of some
|> virtual during a library update.
|> 
|> This approach will save people who misdefine the virtual definition in
|> a minor way.
|> 
|> This approach will be backward compatible, since redeclaration of the
|> virtual function in the derived class definition will have no effect.
|> 
|> 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>

--
Joe Buck
jbuck@galileo.berkeley.edu	 {uunet,ucbvax}!galileo.berkeley.edu!jbuck