Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!bionet!agate!darkstar!ucschu.ucsc.edu!ericg
From: ericg@ucschu.ucsc.edu (Eric Goodman)
Newsgroups: comp.lang.c++
Subject: Re: Seeking neat way to do binary "virtual" functions.
Message-ID: <13683@darkstar.ucsc.edu>
Date: 21 Mar 91 21:14:22 GMT
References: <NGO.91Mar19114016@tammy.harvard.edu>
Sender: usenet@darkstar.ucsc.edu
Distribution: comp
Organization: UC Santa Cruz
Lines: 45

In article <NGO.91Mar19114016@tammy.harvard.edu> ngo@tammy.harvard.edu 
(Tom Ngo) writes:
> I would appreciate any suggestions.  Do people consider this a
> fundamental limitation of C++, that the only way to safely convert a 
> pointer to a class to a pointer to one of its derived classes is
> through a virtual function call?

I've been running into the problem myself.  With binary operators of 
unknown actual type only the first object gets run time determined.  To test
type compatibility for two arbitrary base class references there is no way to
determine whether or not they are "the same" other than that they are derived
from the same class.

What I want:

class B {
     virtual B& operator+(B&);
};
class D: public B{
     B& operator+(D&);
};

the D::operator+() function is not overloaded.  I'd like a mechanism that 
would check the actual type of the second arguent, and call the correct 
function at run time:

B& f(B& one, B& two) {
     return (one+two); // if (either or) both are B's, use B::operator+(B&)
                                    //  if both are D's, use 
                                    //  D::operator+(D&)
};
I put the "either or" in parentheses because it is not apparent to me that 
this is the correct thing to do in the case of an incomplete match.  
Perhaps B should define an "operator+mismatch()" that gets called in this 
case? 

I almost consider it a limitation in the language, but the overhead of 
doing something like this implicitly seems to me to be very high.  Not 
being a compiler writer myself, I hesitate to condemn others for a problem I 
couldn't fix myself :-).

Eric Goodman, UC Santa Cruz

ericg@ucschu.ucsc.edu  or  @ucschu.bitnet
Eric_Goodman.staff@macmail.ucsc.edu