Re: accessing base members
In article <1154588769.708944.298130@m73g2000cwd.googlegroups.com>,
"Thomas" <thomas@tansasystems.com> wrote:
You could say that a class always is declared as a friend of itself.
Isn't friendship a type relation, and not an object relation? This
implies that every instance is in fact of a different type, or, that
there are two kinds of friendship: type-friendship and
instance-friendship.
And friendship is not inherited in C++, not in the real world ether :)
. That's why your code above doesn't compile. The reason for this
"compiler generated friend class of itself", I guess, is that if the
copy constructor (or asignment operator) should do its job, then it
have to have access to the data of the object it will copy from. If it
didn't, you had to make access functions to all data if you wanted a
copy constructor, and what should the compiler generated copy
constructor do? So for me, to have every class to be friend of itself,
is logical.
But why is not friendship inherited? if so what would be the point of
having protected members? Protected members should only be accessed by
objects of the derived class or objects of the class declaring the
member. If every class was friend with inherited classes then the
private member would act protected to the derived class but private to
the outside world. You would never have real private members.
I agree that this would destroy encapsulation.
But inheriting friendship is not needed for this.
- The compiler knows we are in the context of a member function.
- The compiler knows we're accessing an object as a base type.
- It already works this way for privates and statics.
It does work with static members however:
class A {
protected:
int x;
static void set_x (A& a, int xx) { a.x = xx; }
};
class B : public A {
public:
void f (A& a) { set_x (a, 0); } // <-- ok
};
set_x(..) is protected in A, so B should inherit this function, and
here you call set_x(..) class B. So this should be OK. The logic is of
couars, that if set_x is protected, all derived class can accsess this
functin by calline set_x(..) :)
Why is the same not true for a non-static member function? That is, if
I declare set_x as non-static member in A, I cannot call it on an
instance other then 'this':
void B::f(A& a) { set_x (a, 0); } // <-- ok
void B::f(A& a) { a.set_x (0); } // <-- error
I'm trying to think of an example where allowing access on protected
members in a member function via a pointer that is not 'this' causes
havoc (break encapsulation), but I can't think of any.
I know my explanations is not allways perfect, but I hope this helps.
-Thomas
Maybe I should rephrase my question: why is 'this' special?
In the sense that in a member function of a type derived from T, I can
only access protected base members via 'this', but not via any other
pointer T. Is this the same in all OO languages? And is there a deep
reason for it, or is it just 'convenience' for compiler builders.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]