Operator overloading and access to private members

[obaqueiro]

Hello, reading the Thinking in C++ book, i came into this code
snippter:


----------
#include <...>...
// code ommited

class Integer {
int i;

public:
Integer (int ii) {i = ii}

const Integer operator+ (const Integer & rv) const {
return Integer (i+rv.i); //
------ Isn't rv.i not visible ?? XXX
}

const Integer operator= (const Integer & rv){...
//code ommited}
};

int main (){
Integer I(1), J(2), K(3);
K = I+J;

// This does not compile... of course
// cout << K.i;
}


-----------

This indeed compiles (in GCC 4). What I can't fully understand why, in
the line market with the XXX, the function access rv.i where i is a
private member of the class Integer. Isn't rv.i supposed to be
inaccessible ? if I try to access K.i in main (the commented code) the
compiler does throw a "Integer::i is private" error. I would expect
the same in the other case.

So I think I am missing something, and the specific question would be
why does this happens? is there any special "visibility" for the
members of the parameters provided when overloading an operator (i.e.,
is it possible to see all the private members of the parameters?)

Thank you!

 

[Victor Bazarov]

Hello, reading the Thinking in C++ book, i came into this code
snippter:


----------
#include <...>...
// code ommited

class Integer {
int i;

public:
Integer (int ii) {i = ii}

const Integer operator+ (const Integer & rv) const {
return Integer (i+rv.i); //
------ Isn't rv.i not visible ?? XXX

Why is it not visible? This function is a member of 'Integer',
it has access to private members of the class.

}

const Integer operator= (const Integer & rv){...
//code ommited}
};

int main (){
Integer I(1), J(2), K(3);
K = I+J;

// This does not compile... of course
// cout << K.i;
}


-----------

This indeed compiles (in GCC 4). What I can't fully understand why, in
the line market with the XXX, the function access rv.i where i is a
private member of the class Integer. Isn't rv.i supposed to be
inaccessible ?

Private members are accessible to all members of the same class and
to the class' friends.

if I try to access K.i in main (the commented code) the
compiler does throw a "Integer::i is private" error. I would expect
the same in the other case.

Why would you?

So I think I am missing something, and the specific question would be
why does this happens? is there any special "visibility" for the
members of the parameters provided when overloading an operator (i.e.,
is it possible to see all the private members of the parameters?)

Just read the damn book again. Doesn't it explain what 'private'
means?

V

 

[red floyd]

Hello, reading the Thinking in C++ book, i came into this code
snippter:


----------
#include <...>...
// code ommited

class Integer {
int i;

public:
Integer (int ii) {i = ii}

const Integer operator+ (const Integer & rv) const {
return Integer (i+rv.i); //
------ Isn't rv.i not visible ?? XXX
}

const Integer operator= (const Integer & rv){...
//code ommited}
};

int main (){
Integer I(1), J(2), K(3);
K = I+J;

// This does not compile... of course
// cout << K.i;
}


-----------

This indeed compiles (in GCC 4). What I can't fully understand why, in
the line market with the XXX, the function access rv.i where i is a
private member of the class Integer. Isn't rv.i supposed to be
inaccessible ? if I try to access K.i in main (the commented code) the
compiler does throw a "Integer::i is private" error. I would expect
the same in the other case.

So I think I am missing something, and the specific question would be
why does this happens? is there any special "visibility" for the
members of the parameters provided when overloading an operator (i.e.,
is it possible to see all the private members of the parameters?)

rv.i is visible becasue it's a member of Integer. operator+ is also a
member of Integer. What's the problem?

You can't access rv.i from main(), because main() is not a member of
Integer.

 

[pelio]

obaqueiro dixit:

Hello, reading the Thinking in C++ book, i came into this code
snippter:


----------
#include <...>...
// code ommited

class Integer {
int i;

public:
Integer (int ii) {i = ii}

const Integer operator+ (const Integer & rv) const {
return Integer (i+rv.i); //
------ Isn't rv.i not visible ?? XXX
}

const Integer operator= (const Integer & rv){...
//code ommited}
};

int main (){
Integer I(1), J(2), K(3);
K = I+J;

// This does not compile... of course
// cout << K.i;
}


-----------

This indeed compiles (in GCC 4). What I can't fully understand why, in
the line market with the XXX, the function access rv.i where i is a
private member of the class Integer. Isn't rv.i supposed to be
inaccessible ? if I try to access K.i in main (the commented code) the
compiler does throw a "Integer::i is private" error. I would expect
the same in the other case.

It may seem no logical but when you think about it, it is
understandable: if you make *your* "i" member private in *your* class,
it is acceptable to access it from a function *you* define in the same
class. As the codder of the class, you are supposed to do it right (just
like you do when you decide declaring "friend").

Of course, a user of your class has the error.

Just the way I see it.

 

[Christopher]

Hello, reading the Thinking in C++ book, i came into this code
snippter:

----------
#include <...>...
// code ommited

class Integer {
int i;

public:
Integer (int ii) {i = ii}

const Integer operator+ (const Integer & rv) const {
return Integer (i+rv.i); //
------ Isn't rv.i not visible ?? XXX
}

const Integer operator= (const Integer & rv){...
//code ommited}
};

int main (){
Integer I(1), J(2), K(3);
K = I+J;

// This does not compile... of course
// cout << K.i;

}

-----------

This indeed compiles (in GCC 4). What I can't fully understand why, in
the line market with the XXX, the function access rv.i where i is a
private member of the class Integer. Isn't rv.i supposed to be
inaccessible ? if I try to access K.i in main (the commented code) the
compiler does throw a "Integer::i is private" error. I would expect
the same in the other case.

So I think I am missing something, and the specific question would be
why does this happens? is there any special "visibility" for the
members of the parameters provided when overloading an operator (i.e.,
is it possible to see all the private members of the parameters?)

Thank you!

private members of a class are certainly visible to the class itself,
otherwise wouldn't they be left in limbo and be untouchable just
taking up space that is never used?

Review 'scope', 'public', 'protected', and 'private'
It is a very essential concept to understand. If you haven't studied
inheritance yet, these reasoning for these different visibilities will
make much more sense after. I'd recommend studying inheritance
simultaneously.

Make sure you have a solid grasp of these concepts. Too many people
just make it compile without understanding the impact of placing a
method or data member that should be private or protected as public.
Then I get to fix their bugs down the line only to discover the design
was garbage.

GL!

 

[pelio]

Christopher dixit:

private members of a class are certainly visible to the class itself,
otherwise wouldn't they be left in limbo and be untouchable just
taking up space that is never used?

Yes this.privateMember should be but why notThis.privateMember should ?
You did not read the post.

Review 'scope', 'public', 'protected', and 'private'
It is a very essential concept to understand. If you haven't studied
inheritance yet, these reasoning for these different visibilities will
make much more sense after. I'd recommend studying inheritance
simultaneously.

Make sure you have a solid grasp of these concepts. Too many people
just make it compile without understanding the impact of placing a
method or data member that should be private or protected as public.
Then I get to fix their bugs down the line only to discover the design
was garbage.

Hoping you get better at writing code that reading posts.

 

[Bo Persson]

Christopher dixit:

Yes this.privateMember should be but why notThis.privateMember
should ? You did not read the post.

I think he did.

The thing is exactly that notThis is of the same type as this. Members
of a class have access to all other members of the same class, they
are siblings.

This doesn't break encapsulation, because it is the designer of the
class that decides how the class should act. You cannot do this from
the outside.


Bo Persson

 

[Erik Wikström]

I think he did.

The thing is exactly that notThis is of the same type as this. Members
of a class have access to all other members of the same class, they
are siblings.

This doesn't break encapsulation, because it is the designer of the
class that decides how the class should act. You cannot do this from
the outside.

In fact it increases encapsulation, since you would have to make these
members either public or create accessor functions for then to provide
the same kind of functionality if they were not accessible from other
classes of the same type.

 

[pelio]

Bo Persson dixit:

I think he did.

I really think he did not. Sic: "private members of a class are
certainly visible to the class itself, otherwise wouldn't they be left
in limbo and be untouchable" Obviously this statement try tell "i" would
never ever be accessible (ignoring the distinction of the "this"
instance of a class and another instance)

 

[Christopher]

Bo Persson dixit:
Obviously this statement try tell "i" would
never ever be accessible (ignoring the distinction of the "this"
instance of a class and another instance)

Can you please reword this in English and use complete sentences so I
can tell what the hell you are trying to say? I am not nit picky on
grammar, but I cannot even discern the basic idea behind what you are
talking about in order to defend my post.

_If_ a private member was not visible to the class, then it wouldn't
be visible to the class, this instance or any other instance! But who
cares? Private members _are_ visible to the class. Why are you trying
to argue about fantasy rules that do not exist?

 

[Victor Bazarov]

[..]
The thing is exactly that notThis is of the same type as this.
Members of a class have access to all other members of the same
class, they are siblings.

This doesn't break encapsulation, because it is the designer of the
class that decides how the class should act. You cannot do this from
the outside.

In fact it increases encapsulation, since you would have to make these
members either public or create accessor functions for then to provide
the same kind of functionality if they were not accessible from other
classes of the same type.

"... from other objects/instances of the same class/type".

That's with the existing mechanism of access specifiers. It has been
suggested before that for those data members that nobody except their
"owner" instance is allowed to access there has to be some very special
access specifier, like "secret". And the compiler would only allow
access to those inside non-static member functions and only with the
use of 'this->'. The other side has always argued that the need for
such mechanism is essentially non-existent. But the argument does pop
up every now and then. I am sure that "secret" access specifier would
only increase encapsulation, can there be any doubt about it?

V