Re: Is a class a friend of itself?
Pascal J. Bourguignon wrote:
Juha Nieminen <nospam@thanks.invalid> writes:
John wrote:
In the code below, if I define member functions that take an A object,
then I am able to change protected data members of the passed in A
object. Does this mean that all members functions of a class or friend
functions of the same class? This surprised me.
Why does it surprise you? Why shouldn't a class have access to its own
members?
That's the question.
If you have two objects of the same class, why should the first object
be allowed to fiddle with the fields of the other object:
void MyClass::myMethod(MyClass* other){
other->field=42; // !!!
}
Worse, other may actually be of a subclass of MyClass, in which the
implementation of the field is changed (eg.:
SubClass:setField(int aValue){ field=aValue*2; }
int SubClass:getField(int aValue){ return(field/2); }
) and then the fiddling will be wrong.
Unfortunately, C++ doesn't prevent it, and this is surprizing for a
language so up tight.
Not really. (Part of) the point of encapsulation is the hiding of
internal data from code that doesn't/shouldn't know how the internals
work. I find it pretty hard to argue that a class doesn't know about
it's own internals!
There's a lot of cases when this behaviour is important - copy
constructors for one, but also with operator overloading (or doing the
equivalent thing without an operator for it).
For example consider an hypothetical BigNum class. To perform
multiplication between two of these requires detailed information about
the internals of both instances. Are you suggesting that being forced to
expose the guts of the internals via a public get in order to do this
would represent better design?
If you wanted to restrict this, for whatever reason, exactly how would
you do that?
We can only edict a style rule saying that fields should always be
accessed thru setters and getters.
You have no way of knowing whether a pointer is pointing to
the same object as 'this', other than actually making that check every
time a member is accessed, making every access slower. For what purpose?
Not really, with a declaration such as above, you know at least that
the other object has the wanted field. But of course, in presence of
subclasses, it's not enough.
There's still an "IS A" relation there, so the previous comment applies
and it's not like you get access to the internals of the subclass. If
this scenario causes you problems then I'd argue that it's just the
manifestation of an larger problem within your design hierarchy.
Alan