Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!princeton!allegra!alice!bs From: bs@alice.UUCP Newsgroups: comp.lang.c++ Subject: Re: proposed info-hiding mechanism Message-ID: <6763@alice.uUCp> Date: Mon, 30-Mar-87 22:22:55 EST Article-I.D.: alice.6763 Posted: Mon Mar 30 22:22:55 1987 Date-Received: Wed, 1-Apr-87 06:59:00 EST Organization: AT&T Bell Laboratories, Murray Hill NJ Lines: 53 Keywords: friend protected shapiro@inria.UUCP (Marc Shapiro) writes: > class sosObject { > long size; > int fd; > protected: > write_me_to_disk () {return ::write(fd, (void*)this, size);} > } > > class A: public sosObject { > ... > } > > class B: public sosObject { > foo (A *a) { a -> write_me_to_disk(); } // legal ! > } > > The above example shows that even though B is not derived from A, B has > access to A's 'protected' members. Correct. The unit of protection in C++ is a class; not an individual object. There are cases where the class is the ideal unit of protection and cases where the object is. Concievably an ideal language would give the programmer a choice. mikem@otc.UUCP (Mike Mobray) writes: > class Base { > protected: > prot_member(); > }; > > class Derived : public Base { > // Derived can use prot_member() > > friend somefunc(Derived *d) { d->prot_member(); } > > // somefunc should be able to use prot_member() > // for an object of type Derived. In release > // 1.1 this gives an error message complaining > // that prot_member is protected. > }; Again, cfront is correct. A friend does not have access to protected members of a base class of the class it is a friend of. A protected member is accessible by members of a derived class and by friends of its class. In the example above somefunc() is neither a member of Derived nor a friend of Base. One might conceiveably use the less restrictive rule that ``a friend can access anything a member can'', but the implications of such a relaxation of the rules are not obvious and quite nasty to implement.