It seems like an unstated assumption that the classes are the same was
made. ???

Also, I was not aware that two different instances of a class could
access each others' private members, other than through public member
functions or methods.  Is it true that public methods are not required
for this?  I thought that private data members could only be accessed by
the same instance of the class, and not by a different, separate
instance of the class.

Mike Corbeil


Nat Pryce wrote:

> Jean-Francois Bertrand <jfbertrand@bearcreek.com> wrote in article
> <01bc9dfb$a81cc0a0$b1bf1ace@jbertrand>...
> > inline bool MyClass::operator==(MyClass& rhs)
> > {
> >       if (aMember == rhs.aMember)     <=== Isn't that against
> incapsulation
> >               return true;
> >       else
> >               return false;
> > }
>
> No, it *supports* encapsulation.  If individual objects of the same
> class
> could not access each others private member variables, then one would
> have to write public member functions to expose those member variables
>
> in order to be able to write copy constructors and assignment
> operators,
> for example.
>
> Exposing such implementation details in the public interface breaks
> encapsulation.  Allowing objects to access private members of other
> objects of the same class allows the implementation details to be
> encapsulated within the code for that class and hidden from users of
> the class.
>
> Cheers,
>         Nat.
> ---
> [ comp.std.c++ is moderated.  To submit articles: Try just posting
> with your
>                 newsreader.  If that fails, use
> mailto:std-c++@ncar.ucar.edu
>   comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
>   Moderation policy:
> http://reality.sgi.com/austern/std-c++/policy.html
>   Comments? mailto:std-c++-request@ncar.ucar.edu
> ]
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

"Jean-Francois Bertrand" <jfbertrand@bearcreek.com> wrote
[edited for brevity]:
>class MyClass { /*...*/
> int aMember;
>};
>
>inline bool MyClass::operator==(MyClass& rhs)
>{
> if (aMember == rhs.aMember) <=== Isn't that against incapsulation
>  return true;
> else
>  return false;
>}

This is a common question, and a good one.  Short answer: If member functions
of MyClass did not have access to rhs's private data in a case like this, it
would generally be impossible to write copy construction or copy assignment.

It's not a violation of encapsulation, for no outside clients gain any access
to the internals of MyClass... only MyClass's member functions do, which is
what it means to be a "member" of something restricted/exclusive.


---
Herb Sutter (mailto:herbs@cntc.com)

Current Network Technologies Corp. (http://www.cntc.com)
2695 North Sheridan Way, Suite 150, Mississauga ON Canada   L5K 2N6
Tel 416-805-9088   Fax 905-822-3824
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Jean-Francois Bertrand wrote:
>
> Recently I was implementing == and < operator in a class and I made a typo
> and to my surprise, it worked. Let me show you:
>
> class MyClass
> {
> public:
>         MyClass();
>         ~MyClass();
>         int GetaMember();
>         bool operator==(MyClass&);
>         bool operator<(MyClass&);
>
> private:
>         int aMember;
>
> };
>
> inline bool MyClass::operator==(MyClass& rhs)
> {
>         if (aMember == rhs.aMember)     <=== Isn't that against incapsulation
>                 return true;
>         else
>                 return false;
> }
>
> I know it works and I know its legal to do that (I looked in my books) but
> I would like to know why it was implemented that way in the C++ language.

It's because C++ supports encapsulation on per class basis but not on a
per instance basis. If C++ supported encapsulation on a per instance
basis then the decision whether accessing  rhs.aMember  is legal or not
could only be taken at runtime by checking if  this == &rhs .

The concept of encapsulation in C++ is intended to give implementors of
classes the ability to restrict use of their classes in order to
prevent abuse, keep integrity, keep future compatibility and so on of
their classes. These implementors know all (that is necessary) about
the instances of their classes and there is no need to hide anything
from them.

I hope this helps you,

Martin Huber.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <33e1f4b1.3775138@herbs>, herbs@cntc.com wrote:
>"Jean-Francois Bertrand" <jfbertrand@bearcreek.com> wrote
>[edited for brevity]:
>>class MyClass { int aMember; };
>>
>>inline bool MyClass::operator==(MyClass& rhs) {
>>       if (aMember == rhs.aMember) return true; <=== Isn't that against incapsulation
>>       else return false;
>>}

>This is a common question, and a good one.  Short answer: If member functions
>of MyClass did not have access to rhs's private data in a case like this, it
>would generally be impossible to write copy construction or copy assignment.

I have wrestled with this on occasion, because I often have methods/data which
any member function of a given instance of a class should be able to
call/alter, but which no other instance should be able to use.  As you note,
copy constructors are the big problem, as they need to get to the data of
another instance.

I wished for a keyword like "isolated" that would allow only calls via the
this pointer to succeed.  I did create a hack that passed in the this pointer
to the various functions and did a run time check, but it was slow, did not
cause actual isolation, etc.  Still. it pointed out that the language could
have been implemented in that way.  It also pointed out that this keyword
implied another friend-like keyword that turned it off.

The idea of isolated data did work when the member data was one large heap of
data, like 10K of image data or some such.  Objects did not contain thier
internal data, only a key, and a generic database object would ask for keys
and this pointers before returning a writable copy of the internals.
Anything with a matching this pointer could write it, while other objects of
the same class could only read it, and those without the key were unable to
see it at all.

>It's not a violation of encapsulation, for no outside clients gain any access
>to the internals of MyClass... only MyClass's member functions do, which is
>what it means to be a "member" of something restricted/exclusive.

It is not a violation of encapsulation on an object level, but it is one on an
instance level.  If you have instances that should somehow disallow outside
forces to change thier member data, then you have some trouble expressing the
idiom in C++.  It can be done, but it is not terribly easy.  It rarely seems
to be a problem in practice, because you can use envelope/letter classes to
isolate the classes with real access to the data anyway, so it is only code
writen by the system designers that can get to it, not code written by
outside clients.

Scott

Scott Ellsworth          scott@eviews.com
"When a great many people are unable to find work, unemployment
results" - Calvin Coolidge, (Stanley Walker, City Editor, p. 131 (1934))
"The barbarian is thwarted at the moat." - Scott Adams
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Jean-Francois Bertrand <jfbertrand@bearcreek.com> wrote in article
<01bc9dfb$a81cc0a0$b1bf1ace@jbertrand>...
> inline bool MyClass::operator==(MyClass& rhs)
> {
>  if (aMember == rhs.aMember) <=== Isn't that against incapsulation
>   return true;
>  else
>   return false;
> }

No, it *supports* encapsulation.  If individual objects of the same class
could not access each others private member variables, then one would
have to write public member functions to expose those member variables
in order to be able to write copy constructors and assignment operators,
for example.

Exposing such implementation details in the public interface breaks
encapsulation.  Allowing objects to access private members of other
objects of the same class allows the implementation details to be
encapsulated within the code for that class and hidden from users of
the class.

Cheers,
 Nat.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Because your operator is a member of MyClass as is rhs.  Protection is
class based, not object based.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Recently I was implementing == and < operator in a class and I made a typo
and to my surprise, it worked. Let me show you:

class MyClass
{
public:
 MyClass();
 ~MyClass();
 int GetaMember();
 bool operator==(MyClass&);
 bool operator<(MyClass&);

private:
 int aMember;

};

inline bool MyClass::operator==(MyClass& rhs)
{
 if (aMember == rhs.aMember) <=== Isn't that against incapsulation
  return true;
 else
  return false;
}

I know it works and I know its legal to do that (I looked in my books) but
I would like to know why it was implemented that way in the C++ language.

Thanks for your time


Jean-Francois Bertrand
jfbertrand@bearcreek.com
Software developer
Bear Creek Technologies
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]