Operator overloading and access to private members

Discussion in 'C++' started by obaqueiro, Feb 15, 2008.

  1. obaqueiro

    obaqueiro Guest

    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!
    obaqueiro, Feb 15, 2008
    #1
    1. Advertising

  2. obaqueiro wrote:
    > 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
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, Feb 15, 2008
    #2
    1. Advertising

  3. obaqueiro

    red floyd Guest

    obaqueiro wrote:
    > 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.
    red floyd, Feb 15, 2008
    #3
  4. obaqueiro

    pelio Guest

    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.
    pelio, Feb 15, 2008
    #4
  5. obaqueiro

    Christopher Guest

    On Feb 15, 11:28 am, obaqueiro <> wrote:
    > 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!
    Christopher, Feb 15, 2008
    #5
  6. obaqueiro

    pelio Guest

    Christopher dixit:
    > On Feb 15, 11:28 am, obaqueiro <> wrote:
    >> 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?


    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.

    > GL!
    >
    pelio, Feb 16, 2008
    #6
  7. obaqueiro

    Bo Persson Guest

    pelio wrote:
    > Christopher dixit:
    >> On Feb 15, 11:28 am, obaqueiro <> wrote:
    >>> 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?

    >
    > 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
    Bo Persson, Feb 16, 2008
    #7
  8. On 2008-02-16 10:48, Bo Persson wrote:
    > pelio wrote:
    >> Christopher dixit:
    >>> On Feb 15, 11:28 am, obaqueiro <> wrote:
    >>>> 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?

    >>
    >> 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.


    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.

    --
    Erik Wikström
    Erik Wikström, Feb 16, 2008
    #8
  9. obaqueiro

    pelio Guest

    Bo Persson dixit:
    > pelio wrote:
    >> Christopher dixit:
    >>> On Feb 15, 11:28 am, obaqueiro <> wrote:
    >>>> 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?

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

    >
    > 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)
    pelio, Feb 17, 2008
    #9
  10. obaqueiro

    Christopher Guest

    On Feb 17, 1:27 am, pelio <> wrote:
    > 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?
    Christopher, Feb 18, 2008
    #10
  11. Erik Wikström wrote:
    > On 2008-02-16 10:48, Bo Persson wrote:
    >> [..]
    >> 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
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, Feb 19, 2008
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. CoolPint
    Replies:
    8
    Views:
    976
    Jeff Schwab
    Dec 14, 2003
  2. Andreas
    Replies:
    6
    Views:
    1,001
    Andreas
    Mar 5, 2006
  3. siddhu
    Replies:
    10
    Views:
    609
    James Kanze
    May 11, 2007
  4. Replies:
    11
    Views:
    558
  5. Replies:
    2
    Views:
    311
Loading...

Share This Page