why C++ object can access its data member without via getter function??

[blueblueblue2005]

here is a friend function of Class Array, which has two private data
member: int size, int *ptr

// Array's public member function to return size
int getSize() const { return size; }

friend istream &operator>>(ist ream &in, Array &a)
{
for(int i=0; i<a.size; i++)
// do something
return in;
}

here is my question: a is an object of Array, but in the for loop
condition, a access its private member size directly, instead of
calling getSzie(), like a.getSize(), does this violate the data
encapsulation principle? does anyone else(except me) think c++ is
stupid in some ways?

thanks a lot

[Jakob Bieling]

"blueblueblue20 05" <zh******@gmail .com> wrote in message
news:11******** **************@ g14g2000cwa.goo glegroups.com.. .

here is a friend function of Class Array, which has two private data
member: int size, int *ptr

// Array's public member function to return size
int getSize() const { return size; }

friend istream &operator>>(ist ream &in, Array &a)
{
for(int i=0; i<a.size; i++)
// do something
return in;
}

here is my question: a is an object of Array, but in the for loop
condition, a access its private member size directly, instead of
calling getSzie(), like a.getSize(), does this violate the data
encapsulation principle? does anyone else(except me) think c++ is
stupid in some ways?

It does what you tell it to. If you want stupid things, do them, but
do not blame C++

I can only guess at the real code snippet we are talking about, but
'friend' means exactly what you are getting: access to the internal data
structures. Use it, if you absolutely must, otherwise, just keep away
from it.

hth
--
jb

(reply address in rot13, unscramble first)

[James Daughtry]

> does this violate the data encapsulation principle?
No.

does anyone else(except me) think c++ is stupid in some ways?

Of course C++ is stupid in some ways, but there's a difference between
stupid because it's stupid and stupid because you don't fully
understand the concept, or the intention of a feature.

[blueblueblue2005]

right, totally agree with you, James!!

[Rolf Magnus]

blueblueblue200 5 wrote:

here is a friend function of Class Array, which has two private data
member: int size, int *ptr

// Array's public member function to return size
int getSize() const { return size; }

friend istream &operator>>(ist ream &in, Array &a)
{
for(int i=0; i<a.size; i++)
// do something
return in;
}

here is my question: a is an object of Array, but in the for loop
condition, a access its private member size directly, instead of
calling getSzie(), like a.getSize(), does this violate the data
encapsulation principle?
Yes.
does anyone else(except me) think c++ is stupid in some ways?

You are the one who made it a friend, allowing it to access the private
data. If you think that is stupid, don't do it. C++ is specifically
designed to give you a lot of freedom, but with freedom always comes
responsibility.

[Wisdo Tang]

if you don't like it , you can ignore as you consider.
but maybe one day you'll find such directl access
is usefully and powerfull. especially in C++, some other
rules are give to protecte from this kind of violation flooded.

C++'s other design principle is "it may let you do
in various way and technique"

you can use it,when you find that it's useful and flexilbe.

regards

[Greg]

blueblueblue200 5 wrote:

here is a friend function of Class Array, which has two private data
member: int size, int *ptr

// Array's public member function to return size
int getSize() const { return size; }

friend istream &operator>>(ist ream &in, Array &a)
{
for(int i=0; i<a.size; i++)
// do something
return in;
}

here is my question: a is an object of Array, but in the for loop
condition, a access its private member size directly, instead of
calling getSzie(), like a.getSize(), does this violate the data
encapsulation principle? does anyone else(except me) think c++ is
stupid in some ways?

In order to demonstrate a design flaw in C++ (or in any other
programming language), one needs an example of how this flaw affects
(or prevents the implementation of) a sound programming design. In this
case, the argument would be that C++'s support for friend declarations
makes it impossible to implement the solid design of class Array.

But is the Array class well designed? The first question that anyone
would ask, is why Array makes operator>> a friend, if operator>> can be
implemented using only those methods of A that are public? Why grant
operator>> access to A's private data members when no such access is
needed? Applying the principal of encapsulated design, it is clear that
Array should not grant such access to operator>>. So the case being
made: that C++'s support for friend declarations is "stupid", fails
because the Array class used as an example has a design flaw that no
one should want to implement - in C++ or in any other programming
language.

It is also possible to work from the other direction. Let's assume that
there is no support for friend declarations in C++. Access to classes'
private methods and data members would only be allowed within the
implementation of the class itself.

Now would it be possible to create a solid design for a program where
external access to a class's private data would be needed? The answer
would be "yes" and such cases can be found in the standard library
itself. There are many instances, particular in I/O operations, where
external access to a class's internal buffers is part of a solid
design.

Without C++'s support for friend declarations, those buffers would have
to be declared public - but to do so would violate encapsulation.
Keeping them private would prevent the implementation of a well
designed set of I/O operators. The solution? Of course it's the friend
declaration.

Far from being a defect of the language, C++'s friend declarations
allow programmers to implement solid designs that could not be
implemented without selective access to private data, or that could be
implemented only in ways that would violate the principles of
encapsulation.

Greg