Thomas J. Gritzan wrote:
Siam schrieb:
>>>I couldn't quite believe it,
Why?
I dont see why encapsulation of private data shouldnt hold between
objects of the same class. They are objects in their own right, and
their members have been made private for a good reason.
Think about your class person and it's copy constructor.
How would it copy the private parts of the class? Should you declare
the class person as its own friend?
Well, no, but you're trying to explain the [access] mechanism in its own
terms ["declare as friend"]. What the OP would rather see is something
of this sort:
class Person {
private:
Type stuff;
really_private:
OthertypeType valueable_stuff ;
public:
Person(Person& from) : stuff(from.stuf f),
// now, pay attention here:
valueable_stuff (
from.grant_spec ial_access(this , &Person::valuea ble_stuff)
)
{}
template<class PM, class ToPM grant_special_a ccess(To t, PM what)
{
// some fancy mechanism
// checking if 't' has access to _my_ privates
if (granted)
return what;
else
return 0;
}
};
Which actually looks like a security mechanism for safeguarding private
data members on per-instance basis. It's possible. Is it needed? Not
in our everyday programming activities. When is it needed? Well, when
some fancy system with inter-instance barriers is created... The language
does not have those things built-in. 'private' is not "per-instance", it
is "per-class". For whatever reason the OP thought otherwise.
Forming certain expectations before actually _learning_ the language, i.e.
coming to the language with preconceptions of how certain things should
behave, is often the cause of confusion and learning problems. One often
needs to "un-learn" things before one's ready to absorb real knowledge.
Nowadays we don't get asked often, but I remember when every fifth post
here was "what operator do I use to calculate Yth power of X? X^Y or
X**Y don't seem to work!"
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
