Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!rose!juan
From: juan@rose.ACA.MCC.COM (John Reynolds)
Newsgroups: comp.lang.c++
Subject: Friends and Overloading
Message-ID: <1655@rose.ACA.MCC.COM>
Date: 18 Dec 90 16:22:10 GMT
Reply-To: juan@radar.UUCP ()
Distribution: na
Organization: MCC  Austin, Texas
Lines: 59

While attempting to create a fixed length and variable
length array class, I discovered the following interesting
effect of overloading the = operator using a friend function.

In order to 'copy' each class to the other, I created a friend
function for operator= for each permutation, (varray,varray),
(varray,farray), (farray,varray), and (farray,farray).

class farray
{
  // some stuff
public:
  void friend operator=(farray,varray);
  // more stuff
}

void operator=(farray,array)
{
  // some code
}

This worked fine, using the friend functions I was able to copy
with ease between the two classes. 

The hidden time bomb came when I tried to use = with any other
classes.  Since I had used global overloading of = in the friend
functions, the compiler would no longer default to bitwise copy
for the other classes.  Apparently once you overload = for any
classes as a friend function, you must overload it explicitly
for any classes it is applied to.

I escaped this morass by making my farray and varray classes
friends of each other and using standard overloading of =.
This has the disadvantage of allowing each class access to all
of the data of the other, but it does not create a globally
overloaded = with the problems outlined above.

class farray
{
  friend class varray
public:
  void operator=(varray);
}

void farray::operator=(varray n)
{
  // some code
}

This is a very subtle (to me) effect which I have not seen
in the literature.  I understand the difference between the
two cases, but I do not understand why the compiler does not
"fall back" on bitwise copy if an explicit overload is not 
supplied ( I expect a warning message, not an error ).

I hope this helps you avoid the same pit.

John Reynolds
juan@mcc.com