Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!spool.mu.edu!uunet!world!wmm
From: wmm@world.std.com (William M Miller)
Newsgroups: comp.lang.c++
Subject: Re: Can I make overloaded operator functions virtual?
Message-ID: <1991Mar23.020108.24154@world.std.com>
Date: 23 Mar 91 02:01:08 GMT
References: <1991Mar21.184133.14506@watson.ibm.com> <1991Mar22.044801.26365@world.std.com> <1991Mar22.181007.18431@watson.ibm.com>
Distribution: usa
Organization: The World Public Access UNIX, Brookline, MA
Lines: 68

mittle@blinn.watson.ibm.com (Josh Mittleman) writes:
> To summarize:
>
> Derived d, e;
> Base b, c;
> Base &br1 = d, &br2 = e, &br3 = b, &br4 = c;
>
> Derived::operator==(Derived&) invoked by (d == e), (br1 == br2),
>                                          (br1 == e), (d = br2)
>
> Derived::operator==(Base&)    invoked by (d == b), (br1 == b), (d = br3),
>                                          (br1 = br3)
>
> Base::operator==(Base&)       invoked by (b == c), (b == d), (b == br1),
>                                          (b = br3), (br3 = c), (br3 = d),
>                                          (br3 = br1), (br3 = br4)
>
> I may be missing something, but I see neither ambiguity nor danger in this
> system.

Sorry, this is a much more ambitious modification to the existing virtual
mechanism than I had realized.  When you originally said,

> class Base
> {
> public:
>   virtual int operator==(const Base&);
> };
>
> class Derived : public Base
> {
> public:
>   int operator==(const Derived&);
> };
>
> We would really like Derived::operator== to match the virtual
> Base::operator==, but we need to be able to treat the argument as a
> Derived&.

I had understood that to mean that all you wanted was for
Derived::operator==(const Derived&) to override Base::operator==(const
Base&) and nothing more.  That proposal, which I have seen made by others,
leads directly to the possibility of passing a Base object as the argument
to Derived::operator==(const Derived&), as I pointed out.

What you are asking for, though, as I understand it, is that virtual
dispatch be based not only on the type of the object for which the member
function is invoked but also on the type(s) of the argument(s).  This looks
awfully hard to me unless you go to a full-blown dynamic type resolution
scheme like Objective-C or Smalltalk -- or are you suggesting limiting it
only to 2-level matching (i.e., 1 argument), with the argument required to
be a pointer or reference to the base class first declaring the virtual
function?  If so, it's pretty straightforward to figure out how to do that
with double tables and one extra level of indirection, but it seems like a
rather arbitrary restriction.

Anyhow, this is a new approach to the issue that I hadn't seen before, and
my earlier reaction was based on insufficient information.  I'd be
interested in seeing a more complete writeup on it detailing exactly what
you're proposing (number and type of arguments on which virtual dispatch
could be based, possible implementation strategies, impact on compatibility
with existing code, utility, etc.).  Also, would you be advocating applying
the proposal to non-member overloaded operators?  If you can do virtual
dispatch not just on object type but on operand type as well, it would seem
natural to want "virtual" non-member operators, too.

-- William M. Miller, Glockenspiel, Ltd.
   wmm@world.std.com