Article View: comp.std.c++
Article #2944Re: Encapsulation and friends
From: Steve Clamage
Date: Sat, 16 Dec 1995 07:43
Date: Sat, 16 Dec 1995 07:43
48 lines
2544 bytes
2544 bytes
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. ]
Technical Details
Message-ID:
<4asbil$ifn@engnews2.Eng.Sun.COM>Path:
arc1-ca.pugleaf.net!newsxfer.itd.umich.edu!agate!agate!mattReferences:
<4aqsbs$508@steel.interlog.com>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!newsxfer.itd.umich.edu!agate!agate!matt From: clamage@Eng.Sun.COM (Steve Clamage) Newsgroups: comp.std.c++ Subject: Re: Encapsulation and friends Date: 16 Dec 1995 07:43:24 GMT Organization: Sun Microsystems Inc. Approved: matt@Austern (Matt Austern) Message-ID: <4asbil$ifn@engnews2.Eng.Sun.COM> References: <4aqsbs$508@steel.interlog.com> Reply-To: clamage@Eng.Sun.COM NNTP-Posting-Host: austern.hip.berkeley.edu