Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!shelby!agate!pasteur!galileo.berkeley.edu!jbuck From: jbuck@galileo.berkeley.edu (Joe Buck) Newsgroups: comp.lang.c++ Subject: Re: Why just public, protected, and private? Keywords: protection categories, modularity Message-ID: <11006@pasteur.Berkeley.EDU> Date: 11 Feb 91 19:40:55 GMT References: <1991Feb9.021746.13835@xanadu.com> <3811@lupine.NCD.COM> Sender: news@pasteur.Berkeley.EDU Reply-To: jbuck@galileo.berkeley.edu (Joe Buck) Lines: 30 In article , fuchs@tmipi4.telematik.informatik.uni-karlsruhe.de (Harald Fuchs) writes: |> rfg@NCD.COM (Ron Guilmette) writes: |> |> >In article <1991Feb9.021746.13835@xanadu.com> ravi@xanadu.com (Ravi Pandya) writes: |> >>For some strange reason, C++ allows private messages to be sent either |> >>to this or to another compatible object, but protected messages can |> >>only be sent to this. |> |> >I don't have my copy of E&S handy, but I believe that your statement is |> >incorrect. |> |> Me too. I think what Ravi meant was the following: you can call private |> member functions of other objects _of the same type_ (because the unit |> of protection in C++ is the class rather than the instance), but you can |> call protected member functions (in the base type) only for _this_ object, |> not for other objects of the base type. This is not correct either. Given classes Base and Derived, and protected member function Base::func(), a member function of class Derived can call func() on itself *or* on another object of class Derived. It may not call func(), however, on objects of class Base or on objects of other classes derived from Base and not derived from Derived. Why, you ask? So protectedness is not too weak a concept in tree-type class hierarchies, mainly; as you work with it more the reason become more clear. -- Joe Buck jbuck@galileo.berkeley.edu {uunet,ucbvax}!galileo.berkeley.edu!jbuck