In article <D713vH.C7K@research.att.com>,
   ark@research.att.com (Andrew Koenig) wrote:
>In article <3mj8fb$q5l@liberator.et.tudelft.nl> Sander de Jong
<jongs@nlr.nl> writes:
>
>> Does anybody have an answer to the following question:
>> in C++ it is allowed for an object of a certain class to access
>> private members of some other object of the same class. Why?
>> Clearly this is violating every principle of encapsulation!

No it isn't, and the reason involves the definition of "client".

1. All other classes, including clients, have no such liberty (unless of
course specifically declared as friends, but then they're no longer just
clients).  This is what encapsulation means; the private implementation is
completely hidden to clients.

2. Objects of the same class are not clients.  Further, they only have such
liberty when specifically _given_ the other object as a parameter, else they
wouldn't even know about it.  They are only given the object when they need
to do something with is, such as:

>How would you write a copy constructor otherwise?

Indeed.  The alternative is exposing the implementation, or writing a slew
of get() methods (which would then have to be public anyway).  Methods have
class access, not per-object access.


---
Herb Sutter             #include <std_disclaimer.h>
herbs@interlog.com      "Me?  Paranoid?  ... Uh, why do you ask?"

pvnadham@uncc.edu writes:
>Does anybody have an answer to the following question:
>in C++ it is allowed for an object of a certain class to access
>private members of some other object of the same class. Why?
>Clearly this is violating every principle of encapsulation!

No, because you're using the wrong model.  Objects don't access members;
member functions access members.  Protection is based on classes, not
objects.  It's critical to understand this or the rules for protected
members will really confuse you.

If this is a problem in a particular case, you can make a unique derived
class (so that an object whose private members must be *really* private
is the only member of its class).

--
-- Joe Buck  <jbuck@synopsys.com> (not speaking for Synopsys, Inc)
Phone: +1 415 694 1729

    > In article <3mj8fb$q5l@liberator.et.tudelft.nl> Sander de
    > Jong <jongs@nlr.nl> writes:
    >> Does anybody have an answer to the following question: in C++
    >> it is allowed for an object of a certain class to access
    >> private members of some other object of the same class. Why?
    >> Clearly this is violating every principle of encapsulation!

It seems to me that methods actually belong to classes and not
objects.  If this isn't so, why can't I do the following:
class silly
{
  void once() { cerr << "I was already called once\n"; abort(); }
public:
  void call() { call=once; }
};

But if it is true that methods belong to classes, why bother with host
objects?  It seems like everything that can be done with host objects
can also be done with function overloading.

  Jason

Does anybody have an answer to the following question:
in C++ it is allowed for an object of a certain class to access
private members of some other object of the same class. Why?
Clearly this is violating every principle of encapsulation!

example:

void A::someFunction( const A& theA )
{
 // *this can now access anything from theA!!
}

Also the parallel with real life is nowhere: just because I am a
human being and I know what I think, doesn't mean that I know what
some other human being thinks: (s)he will have to tell me via
public interfaces: words, paper, etc.

This question is specifically aimed at those people who have actively
helped to make C++.

Sander de Jong
jongs@nlr.nl

In article <3mj8fb$q5l@liberator.et.tudelft.nl> Sander de Jong <jongs@nlr.nl> writes:

> in C++ it is allowed for an object of a certain class to access
> private members of some other object of the same class. Why?
> Clearly this is violating every principle of encapsulation!

You are right, every method of a class can use the private members and
methods of any other object of the same class.

In C++, the smallest protection unit is the object instead of the
class. C++ provides many mechanisms to partially violate
encapsulation, like friend functions, and your example is
the sadest one; but like friend functions, you are not obliged to use
these 'bad' tricks, if you do not like them.

--
Valery

Does anybody have an answer to the following question:
in C++ it is allowed for an object of a certain class to access
private members of some other object of the same class. Why?
Clearly this is violating every principle of encapsulation!

 I too found this puzzling at first, but convinced
 myself this way...  One goal of abstraction
 and encapsulation is to prevent the change inside a class to
 affect the outside world. But, obviously, the components of the
 class will know this change and be modified accordingly. All
 objects of the class will reflect an identical "change".
 So, this doesn't come in the way of information hiding.

Also the parallel with real life is nowhere: just because I am a
human being and I know what I think, doesn't mean that I know what
some other human being thinks

 but when it comes to possession, any human being knows what
 he is made of, and what others are made of.....

 or, is my analogy way off the mark?!?!

In article <3mj8fb$q5l@liberator.et.tudelft.nl>, Sander de Jong <jongs@nlr.nl> says:
>
>Does anybody have an answer to the following question:
>in C++ it is allowed for an object of a certain class to access
>private members of some other object of the same class. Why?
>Clearly this is violating every principle of encapsulation!

 No, it's not. One view of encapsulation is that its purpose is to
isolate the user of an object from the details of that object's
implementation. That, in turn, means that the user of the object shouldn't
be able to get at features of the object that the designer and the
implementor of the object didn't intend to expose. This says nothing about
how the designer and implementor handle internal details of the class.
 To come at it from another direction, suppose that the rule actually
was that member functions cannot access private data in a different object.
Now try and implement an assignment operator. In order to do it, you
have to provide public access of some sort to every data member that needs
to be copied, including data members that would not otherwise have to be
exposed to the public. This would be a much more serious violation of
encapsulation.
 -- Pete

In article <3mj8fb$q5l@liberator.et.tudelft.nl> Sander de Jong <jongs@nlr.nl> writes:

> Does anybody have an answer to the following question:
> in C++ it is allowed for an object of a certain class to access
> private members of some other object of the same class. Why?
> Clearly this is violating every principle of encapsulation!

How would you write a copy constructor otherwise?
--
    --Andrew Koenig
      ark@research.att.com

>>>>> Andrew Koenig <ark@research.att.com> writes:

> In article <3mj8fb$q5l@liberator.et.tudelft.nl> Sander de Jong <jongs@nlr.nl> writes:
>> Does anybody have an answer to the following question:
>> in C++ it is allowed for an object of a certain class to access
>> private members of some other object of the same class. Why?
>> Clearly this is violating every principle of encapsulation!

> How would you write a copy constructor otherwise?

Inefficiently.

Jason