Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!rutgers!usc!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.90Aug5133851@hobbes.uucp>
Date: 5 Aug 90 17:38:51 GMT
Sender: news@rocket.UUCP
Distribution: comp
Organization: Lockheed Sanders Inc.
Lines: 55


    From: uunet!iad-nxe.global-mis.dhl.com!elw (Edwin Wiles)
    Subject: Re: Can we allow virtual function member declarations to be inherited?

    In article <DOVE.90Jul31222153@rocket.uucp> you write:
    >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.

    Nice idea...  Though without the explicit definition in the derived
    class, how can you be certain that that was what the author of the
    derived class wanted?  Having things happen "automagically" is a good
    way to get non-gurus terribly confused.

Right now you have no way of saying that you want to inherit the
fun/arg spec for the function member.  Once you put a fun/arg spec in
your derived class spec, if the ancester virtual goes away because of
a library change, the compiler will still be happy making you a new
function member starting with your current class.  By allowing the
writer to (optionally) inherit the spec, you give the writer a way to
express his intentions to the compiler without rendering any old code
invalid.

    >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.

    When a base class virtual function has a mismatch between it and a
    derived class virtual function of the same name, it should at least
    generate a warning at compile time.  If it isn't doing that, then I'd
    say the compiler/interpreters are falling down on the job.

This solution has some merits and some problems.  It is better than
the current situation (I don't believe g++-1.37.1 which I have been
using does this).  However, if the writer does intend to start a new
fun/arg in his current derived class (one that matches the function,
but not the arguments of any ancestral spec), won't the compiler
complaint at him?

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>