Private member accessible from another object?

Discussion in 'C++' started by Siam, Aug 1, 2006.

  1. Siam

    Siam Guest

    Hi all,

    I read somewhere that private members of some instance of class A are
    accessible from another instance of the same class. In other words,
    access to private members is done 'on a class by class basis, not on an
    instance by instance basis'. I couldn't quite believe it, and tried it
    out for myself, and was shocked to see it was true... What is the
    reasoning behind this? Why should one Person object be able to see
    another Person object's private parts?

    Cheers,
    Siam
     
    Siam, Aug 1, 2006
    #1
    1. Advertising

  2. Siam wrote:
    > I read somewhere that private members of some instance of class A are
    > accessible from another instance of the same class.


    That's correct.

    > In other words,
    > access to private members is done 'on a class by class basis, not on
    > an instance by instance basis'.


    Right.

    > I couldn't quite believe it,


    Why?

    > and
    > tried it out for myself, and was shocked to see it was true... What
    > is the reasoning behind this?


    It's done for simplicity, performance. Get a copy of D&E and read it.

    > Why should one Person object be able to
    > see another Person object's private parts?


    I think you're assigning too much weight to real-world analogy here.
    Access specifiers in C++ exist for different reasons than privacy laws
    and moral foundations in the real world.

    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, Aug 1, 2006
    #2
    1. Advertising

  3. Siam

    Siam Guest

    > > I couldn't quite believe it,
    >
    > Why?


    I dont see why encapsulation of private data shouldnt hold between
    objects of the same class. They are objects in their own right, and
    their members have been made private for a good reason.

    > I think you're assigning too much weight to real-world analogy here.
    > Access specifiers in C++ exist for different reasons than privacy laws
    > and moral foundations in the real world.


    Hehe maybe, but I'm sure I can think up plenty of real examples where
    it's downright dangerous to allow other objects (albeit of the same
    type) accessing your private members.

    Does this rule also apply extend to inherited classes? Can an object of
    a derived class access private members of an object of the base class,
    and vice versa? (My guess would be yes and no, respectively...)

    Siam
     
    Siam, Aug 1, 2006
    #3
  4. Siam wrote:
    >>> I couldn't quite believe it,

    >>
    >> Why?

    >
    > I dont see why encapsulation of private data shouldnt hold between
    > objects of the same class. They are objects in their own right, and
    > their members have been made private for a good reason.


    Well, vast majority of C++ programmers don't think so or don't care.
    Access specifiers don't exist for security, they exist to help create
    software that works well.

    >> I think you're assigning too much weight to real-world analogy here.
    >> Access specifiers in C++ exist for different reasons than privacy
    >> laws and moral foundations in the real world.

    >
    > Hehe maybe, but I'm sure I can think up plenty of real examples where
    > it's downright dangerous to allow other objects (albeit of the same
    > type) accessing your private members.


    OK, you're on!

    > Does this rule also apply extend to inherited classes? Can an object
    > of a derived class access private members of an object of the base
    > class, and vice versa? (My guess would be yes and no, respectively...)


    Please refer to your C++ textbook for the answer.

    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, Aug 1, 2006
    #4
  5. Siam schrieb:
    >>> I couldn't quite believe it,

    >> Why?

    >
    > I dont see why encapsulation of private data shouldnt hold between
    > objects of the same class. They are objects in their own right, and
    > their members have been made private for a good reason.


    Think about your class person and it's copy constructor.
    How would it copy the private parts of the class? Should you declare
    the class person as its own friend?

    --
    Thomas
     
    Thomas J. Gritzan, Aug 1, 2006
    #5
  6. Thomas J. Gritzan wrote:
    > Siam schrieb:
    >>>> I couldn't quite believe it,
    >>> Why?

    >>
    >> I dont see why encapsulation of private data shouldnt hold between
    >> objects of the same class. They are objects in their own right, and
    >> their members have been made private for a good reason.

    >
    > Think about your class person and it's copy constructor.
    > How would it copy the private parts of the class? Should you declare
    > the class person as its own friend?


    Well, no, but you're trying to explain the [access] mechanism in its own
    terms ["declare as friend"]. What the OP would rather see is something
    of this sort:

    class Person {
    private:
    Type stuff;
    really_private:
    OthertypeType valueable_stuff;
    public:
    Person(Person& from) : stuff(from.stuff),
    // now, pay attention here:
    valueable_stuff(
    from.grant_special_access(this, &Person::valueable_stuff)
    )
    {}

    template<class PM, class To> PM grant_special_access(To t, PM what)
    {
    // some fancy mechanism
    // checking if 't' has access to _my_ privates
    if (granted)
    return what;
    else
    return 0;
    }
    };

    Which actually looks like a security mechanism for safeguarding private
    data members on per-instance basis. It's possible. Is it needed? Not
    in our everyday programming activities. When is it needed? Well, when
    some fancy system with inter-instance barriers is created... The language
    does not have those things built-in. 'private' is not "per-instance", it
    is "per-class". For whatever reason the OP thought otherwise.

    Forming certain expectations before actually _learning_ the language, i.e.
    coming to the language with preconceptions of how certain things should
    behave, is often the cause of confusion and learning problems. One often
    needs to "un-learn" things before one's ready to absorb real knowledge.
    Nowadays we don't get asked often, but I remember when every fifth post
    here was "what operator do I use to calculate Yth power of X? X^Y or
    X**Y don't seem to work!"

    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, Aug 1, 2006
    #6
  7. Siam

    Daniel T. Guest

    In article <>,
    "Siam" <> wrote:

    > I read somewhere that private members of some instance of class A are
    > accessible from another instance of the same class. In other words,
    > access to private members is done 'on a class by class basis, not on an
    > instance by instance basis'. I couldn't quite believe it, and tried it
    > out for myself, and was shocked to see it was true...


    > What is the reasoning behind this?


    The individual who wrote the class is in the best position to know if
    one object of the class should be able to modify the data of another
    object of the class.

    > Why should one Person object be able to see another Person object's
    > private parts?


    Why shouldn't this be the case?
     
    Daniel T., Aug 1, 2006
    #7
    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. Jack Wright
    Replies:
    3
    Views:
    1,632
    Chris Jackson
    Jan 5, 2004
  2. Tim Zych
    Replies:
    3
    Views:
    455
    Tim Zych
    May 12, 2004
  3. Richard
    Replies:
    1
    Views:
    1,796
    Steven Cheng[MSFT]
    Jul 27, 2004
  4. Peng Yu
    Replies:
    3
    Views:
    1,085
    Simon Forman
    Sep 21, 2009
  5. Pavel
    Replies:
    2
    Views:
    413
    Pavel
    May 1, 2011
Loading...

Share This Page