Path: utzoo!attcan!uunet!mcvax!ukc!reading!cf-cm!cybaswan!eeartym
From: eeartym@cybaswan.UUCP (Dr R.Artym eleceng )
Newsgroups: comp.lang.c++
Subject: Re: Friend specifier considered harmful
Message-ID: <76@cybaswan.UUCP>
Date: 12 Sep 88 02:42:39 GMT
References: <61@cybaswan.UUCP> <8160@alice.UUCP>
Reply-To: eeartym@cybaswan.UUCP (Dr R.Artym eleceng )
Organization: University College of Swansea
Lines: 58

In article <8160@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes:

> Obviously not -- I can write a universal Turing machine
> simulator without the friend specifier.  But the real question is:
> Are there problems for which friends are the ``best'' solution?
> My answer is YES.  Friends are useful any time you want to have
> several interrelated classes that can't be naturally described
> by inheritance.

In this circumstance, you should get objects to perform a service for
you by calling their member functions, rather than meddling with their
internals directly.

> For example, a linear algebra package might have Vector and Matrix
> classes.  Although some people might claim that a vector is
> just a 1xN matrix, others might prefer an Nx1 matrix, and
> therefore I suggest that vectors and matrices are really
> different beasts and neither is a species of the other.
> Now, how do you write a function to multiply a Matrix by a
> Vector?  It apparently needs to know about the internal
> representations of both classes.  Moreover, symmetry suggests
> that it should be a member of both or neither -- which
> perforce means neither.  Friends are the only way to make
> this possible.

Why not define the function as an operator in both classes with the other
class as argument?  Then the right one will get invoked depending on the
order of the operands.  Needless to say, the actual code need only appear
in one of them (the other just swaps the arguments around and calls the
former's member function).  In the example that you give, the desire for
symmetry is misfounded:  the code should appear in that class of which a
new object is being created by the operation, ie. if Vector OP Matrix
produces a new Matrix, then all the actual operator code should reside in
a member of Matrix and be called as a service from the corresponding member
of Vector.

> If you are tempted to respond that this just shows that
> matrices and vectors should either be the same class
> or one should inherit from the other, my response is that
> my argument still holds for any two classes that need
> to be linked by some means other than inheritance --
> you won't convince me that friends are unnecessary until
> you have convinced me that no such classes can ever exist.

I would not respond this way!  Quite the opposite --- I say keep them
separate, completely separate, and if there's a service that one can
render the other then invoke it via the regular object access system,
ie. call a member.
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Keywords:  Parallel, Applicative, and Object-Oriented Languages and Systems
---------------------------------------------------------------------------
Dr. Richard Artym,              +   UUCP   :  ..!ukc!pyr.swan.ac.uk!eeartym
Electrical Engineering Dept.,   +   JANET  :  eeartym@uk.ac.swan.pyr
University of Wales,            +   Phone  :  [(0792) or (+44 792)]  295536
Swansea, SA2 8PP,               +   Fax    :  [(0792) or (+44 792)]  295532
U.K.                            +   Telex  :  48358
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~