Topic: Encapsulation and friends


Author: anders@ida.his.se (Anders Eklund)
Date: 1995/12/14
Raw View
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?

--


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         ___
        /   /       /
       /__ /___ ___/___ ___ ___      --  Anders Eklund  anders@ida.his.se --
      /   //  //  //__//   /__       --  Computer Science Department      --
    _/   //  //__//__ /   ___/       --  University of Skovde, Sweden     --

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~







---
[ 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. ]





Author: herbs@connobj.com (Herb Sutter)
Date: 1995/12/15
Raw View
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. ]





Author: clamage@Eng.Sun.COM (Steve Clamage)
Date: 1995/12/16
Raw View
In article 508@steel.interlog.com, herbs@connobj.com (Herb Sutter) writes:
>
>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)...?

My copy of D&E is not handy, so I don't know whether the reasons are
discussed there. But here is how it seems to me:

1. I hope we all agree with the principle that friendship can only be
granted and cannot be seized.

2. A base-class function has no special access to a derived class.

3. A friend class can be viewed as part of the class of which it is a
friend. If friendship were inherited, a friend class would have
priviledges unavailable to member functions. (This is IMHO a weak
argument.)

4. A stronger argument: The owner (i.e. maintainer) of a class must own
the friend function. A derived class owner typically does not own the
base class. I would not want functions I don't own to have special access
to my class -- it would constrain in unknown ways the changes I could make
to my derived class implementation.

Optional inheritance of friendship: First, it isn't clear to me
you would want to say "every friend of every base class is my friend too."
If that capability is not desireable, you would want to specify somehow
which base-class friends were also derived-class friends. Of course you
do that now with a friend declaration for each function.

I think you could make a case that
 friend class B;
should mean that friends of B are also friends of this class. If you
can grant friendship to all of B's members, it doesn't seems dangerous
to grant automatically the same to B's friends.
---
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. ]