From: xvh2179@rchland.vnet.ibm.com (Marshall Cline)
Subject: Re: virtual operators....
Date: Mon, 28 Sep 1992 22:49:02 GMT
Distribution: usa
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM Rochester

In article <rmartin.717210094@thor>, rmartin@thor.Rational.COM (Bob Martin) writes:
|> skochhar@cvbnet.prime.com (Sandeep Kochhar x4618 5-2) writes:
|> |1. Should operator= never be virtual...?
|> 
|> Check out the ARM.  ( I don't have mine with me, so I can't give you a
|> reference).  It will tell you that operator= is not inherited.
..
|> So, you would want to make operator= any time you thought you might be
|> doing polymorphic assigment through a reference....

Sorry, but I have to disagree with the import of your advice.  Mechanically,
you are correct, but the perspective you are giving is IMHO wrong.

Since the compiler synthesizes an assignment operator if you didn't provide
your own, the answer to the original question is `No, operator= should [rarely]
be virtual'.  If you make a base class operator= copy the object's *abstract*
state (via being or calling a virtual), compiler synthesized versions for *all*
derived classes must provide their own operator= that merely calls the base
class' version (which in turn calls the derived class' inner method to do the
real work).

I've been there.  Virtual assignment ops simply don't scale.  I wish it were
otherwise, since assignment is nearly useless at the base class level (I make
all ABC assignment operators `protected:').


|> |2. Similarly, what about operator==,  and other boolean operators...
|> 
|> Although these can be inherited, the same limitations on signature
|> apply.  However, with RTTI there may be some interesting constructs
|> for operator==....

Of course, Bob is testing us here.  He knows that his advice is The Great Fear
of RTTI, and he is actually showing us all The Worst Possible Abuse of RTTI.
Naturally he knows that such uses of RTTI are akin to switching off the type
field, and don't scale well in the real world. Thanks Bob for keeping us alert.
(also, Bob is pointing the way toward replacing double-dispatching, another
difficult-to-maintain construct).

I'm sure what he was hoping we would realize is that virtual functions serve
admirably well for operator==.  However since one usually wants to allow
promotion on the left hand side of an operator==, we usually make operator==
(along with most commutative ops, and a few of the non-commutative ops as well)
into `friend's rather than members.  And since top-level friends can't be
virtual, we make the top-level friend call a hidden virtual to do the real
work.

|> --
|> Robert Martin                        Training courses offered in:
|> R. C. M. Consulting                       Object Oriented Analysis
|> 2080 Cranbrook Rd.                        Object Oriented Design
|> Green Oaks, Il 60048 (708) 918-1004       C++

++Marshall


Marshall P. Cline, Ph.D.
Area: training and consulting in OOA, OOD, and C++.
President, Paradigm Shift, Inc., 65 N. Main, Norwood NY 13668, 315/353-6100
Presently training IBM Rochester MN; contact: 507/253-9234, t/l:553-9234
(cline@parashft.com -and- xvh2179@rchland.ibm.com)
Newsgroups: comp.lang.c++