Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rutgers!att!cbnewsl!dog
From: dog@cbnewsl.ATT.COM (edward.n.schiebel)
Newsgroups: comp.lang.c++
Subject: Re: object-oriented design (was Re: are 'friend's really necessary ??)
Message-ID: <4776@cbnewsl.ATT.COM>
Date: 27 Mar 90 12:41:06 GMT
References: <4568@pegasus.ATT.COM>
Organization: AT&T Bell Laboratories
Lines: 37

From article <4568@pegasus.ATT.COM>, by psrc@pegasus.ATT.COM (Paul S. R. Chisholm):
> A "thing" in this case may be a whole class.  If you're careful, only a
> few functions in class B (e.g., member function foo and static member
> function bar) will need to know about the implementation of class A; in
> which case, only B::foo and B::bar will need be friends of A.  This is
> a Good Thing; it specifically limits what software can mess with an A,
> and what code must be looked at when the implementation of A changes.
> 
> There's still a limitation, in that B::foo and B::bar must be visible
> to A to be friends of A.  That implies that one class's private
> functions can only be friends of another class if the functions are
> public (or possibly protected), or if the whole first class is a friend
> of the second class.  (I *assume* the visibility rules apply to
> friendship.)
> 
Not quite.  A private member function of B cannot be called by an A, but
class A may make a private member of B a friend: B's foo() may
access private parts of A, but A cannot call B::foo().

class B {
public:
  B();
private:
  void B::foo();
}

class A {
public:
  A();

  friend void B::foo();
};

	Ed Schiebel
	AT&T Bell Laboratories
	dog@cblph.att.com