🚀 go-pugleaf

In article eos@mhost.ida.his.se, anders@ida.his.se (Anders Eklund) writes:
>
>Friends break the rules of encapsulation and should be avoided
>as much as possible, but sometimes they must be used anyway.
>When I have used friends they only had to use one or a
>few members of the class. As it is now all members are
>accessible to the friend. I would like to specify which members
>the friend can access. There is no way to do that today, but
>would it not be nice to be able to do so? Any comments?

I disagree with your premise. Friends can be used to violate
encapuslation, but so can the "public:" access specifier. A friend
function does not break encapsulation merely by existing. A friend
function must be declared with the class. The owner of the class
also owns the friend functions.

IMHO you should view a friend as part of the public interface. That
is, from a class design point of view, a friend function is equivalent
to a public static member function: it has no "this" pointer, but can
access the entire class.

The only significant difference is the syntax used to access the function.
For example, an overloaded operator+() as a static member function makes
little sense; you could not use the infix operator notation. As a non-static
member function it is asymetric and thus inconvenient to use. As a friend
function it is convenient to use with no surprises.

If it makes sense to provide a way to limit the access a friend function
has to a class, it must also make sense to limit the access of a member
function, yet nobody ever suggests the latter as a good idea.

It seems to me that fine-grained access control (e.g. function A can
access members x, y, and z; function B can access member x only; function
C can access y and z) would be cumbersome to use and would make maintenance
more difficult. I don't see that it has any advantages.
---
Steve Clamage, stephen.clamage@eng.sun.com

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <4apdff$eos@mhost.ida.his.se>,
   anders@ida.his.se (Anders Eklund) wrote:
>Friends break the rules of encapsulation and should be avoided

No.  See FAQ #24 (http://www.connobj.com/cpp/cppfaq.htm).

>as much as possible, but sometimes they must be used anyway.
>When I have used friends they only had to use one or a
>few members of the class. As it is now all members are
>accessible to the friend. I would like to specify which members
>the friend can access. There is no way to do that today, but
>would it not be nice to be able to do so? Any comments?

In general, having partial friendship (to only certain parts of a class) would 
be a (meagre) step in the direction of what Reenskaug et al describe in their 
OOram book in terms of objects playing different roles at different times, and 
that a particular method in a given object may only be accessed by certain 
roles.  However, partial friendship isn't enough to let you implement what 
Reenskaug is talking about, mainly because friendship isn't inherited.

If friendship were heritable, then you could use mixins to solve the general 
problem of granting friendship to only parts of a class.  I'm about to ask a 
question without having done my homework, but: what were the main reasons 
again for not making friendship heritable (even as an option)...?	

Herb


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Herb Sutter (herbs@connobj.com)

Connected Object Solutions     2228 Urwin - Suite 102     voice 416-618-0184
http://www.connobj.com/      Oakville ON Canada L6L 2T2     fax 905-847-6019


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]