Path: utzoo!attcan!utgpu!watmath!att!mtuxo!mtgzz!drutx!kvt
From: kvt@drutx.ATT.COM (TranKV)
Newsgroups: comp.lang.c++
Subject: Re: Suggestion for enhancing member access mechanism
Keywords: protection members
Message-ID: <12160@drutx.ATT.COM>
Date: 31 Aug 89 18:14:18 GMT
References: <13921@brunix.UUCP>
Reply-To: kvt@drutx.ATT.COM (TranKV)
Organization: AT&T, Denver, CO
Lines: 44

In article <13921@brunix.UUCP> jps@cs.brown.edu (John Shewchuk) writes:
>
>The Situation
>--- ---------
>
>Given a class, X, and another class, Y, that is a friend class of the
>first class, X; we might want classes derived from Y to have access to
>the non-public members of X.
>

According to 
        UNIX System V 
        AT&T C++ Language System 
        Release 2.0
        Product Reference Manual

that's the way it's supposed to work. The manual states under subsection
11.4 "friends":
        "Friendship is inherited but not transitive."
		       ^^^^^^^^^
However, I did try the scenario with Cfront 2.0 and got a syntax error 
for having derived class of Y access private member of class X.

[ John proposes a mechanism for tying access specifier 'friend' with 
  other access specifiers such as 'protected', 'private'. ]

>How about this: if the friend declaration appears in the private area
>of a class definition then the friend has complete access to the
>class.  This is just like the current situation.  However, unlike the
>current situation, classes derived from the friend 
>only have access to the non-private members of the original class.
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You mean "have access to all members of the original class." ??

[ ... other cases ... ]


The proposal looks very interesting since it specializes the scoping of
declarator 'friend'. However, I suspect that, in the first place, we 
have a compiler bug in Cfront 2.0 instead of a lack of features in 
C++ language definition.

Kim Tran
Bell Labs, Denver, CO