Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cica!ctrsol!lll-winken!uunet!mcvax!kth!draken!tut!tukki!sakkinen From: sakkinen@tukki.jyu.fi (Markku Sakkinen) Newsgroups: comp.lang.c++ Subject: Re: access to protected members Message-ID: <1040@tukki.jyu.fi> Date: 21 Jul 89 12:34:22 GMT References: <9630@alice.UUCP> Reply-To: markku@jytko.jyu.fi (Markku Sakkinen) SAKKINEN@FINJYU.bitnet (alternative) Organization: University of Jyvaskyla, Finland Lines: 98 In article masotti@usc.edu (Glauco Masotti) writes: >I had some problems using protected members. I was pretty confident, after >reading the "evolution paper" from Bjarne, that my files would compile, but I >received instead complains from the compiler. I am using g++, 1.35.0+ ... > ... >The following is the example: > ... > >Here a protected member of a class is accessed through a pointer in a member >function of a derived class. >To me this should be allowed, I find pretty counterintuitive the contrary. >I would like to know what people think. If Andrew or Bjarne are listening I >would appreciate very much their response. The essence of Masotti's example compiled all right under release 1.2 (Glockenspiel's Designer C++); I just had to edit a couple of other details. However, checking in Stroustrup's "evolution paper" from the USENIX C++ Workshop 1987, I found a rather clear statement to the contrary on p. 3: "A member or a friend of a derived class has access only to protected members of objects that are known to be of its derived type." (***) (see below) >In any case if I cannot write something like the previous example, I think the >cases where the protection mechanism will help instead of being a burden will >shrink significantly. Therefore the problems protected was intended to solve (as >reported in the evolution paper) will not be solved and we will be forced to >resort again to public everything or make a lot of friends (which in C++ is >not as good as in life :-)). > >-Glauco Masotti > >masotti@lipari.usc.edu In article <9630@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes: > ... >The idea of `protected' is to nominate parts of a class that may >only be used as scaffolding on which to build derived classes. > ... > >Although this treatment seems counterintuitive at first, there >are several reasons for it. > >First, if C++ did not restrict things this way, anyone could >circumvent protection for any protected member of any object >merely by deriving a dummy class as shown above. This argument is valid, but not yet overwhelming: there are so many means to circumvent all kinds of protection in C++ anyway. >Second, it is quite easy to make things less restrictive if >that's what you want: in this example, for instance, you could >make Y a friend of X or make X::x public. It is much harder >to make things more restrictive. This suggestion is exactly what Masotti protested against under (***)! >Most of us who have grappled with this problem have found that >there's often a way of doing what we want without running afoul of >the protection restrictions. The solution, once found, may >well be cleaner than the original version. Try it and see. This sounds like the Oracle of Delfoi (Delphi) - leaves me puzzled. If it means e.g. that one should sometimes add more public functions to the base class than have originally been defined, to allow the orderly handling of some private or protected variables, I can agree. >-- > --Andrew Koenig > ark@europa.att.com There are more reasons than (***) why it could be recommendable to allow a member or friend function of a derived class to access protected "members" (I do dislike the meaning given to the word 'member' in C++ literature) of base class objects: 1. Encapsulation in C++ is otherwise on the level of _classes_, as opposed to Smalltalk (every object encapsulated from all others) and Simula (no encapsulation); this would be more analogous. 2. The rules for protected parts would be a little simpler. 3. It would be compatible with earlier versions of C++ (as noted in the beginning of this posting). However, interpreting 'protected' like this would logically require that one could declare something similar to friend classes and functions, i.e. access rights to protected members for some others beside derived classes. Perhaps 'cousin' would do - although I have claimed to oppose to anthropomorphic terminology. See the suggestion for 'acquaintance' in my paper in SIGPLAN Notices, December 1988. Markku Sakkinen Department of Computer Science University of Jyvaskyla (a's with umlauts) Seminaarinkatu 15 SF-40100 Jyvaskyla (umlauts again) Finland