Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Private member accessible from another object?

Reply
Thread Tools

Private member accessible from another object?

 
 
Siam
Guest
Posts: n/a
 
      08-01-2006
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

 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      08-01-2006
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


 
Reply With Quote
 
 
 
 
Siam
Guest
Posts: n/a
 
      08-01-2006
> > 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

 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      08-01-2006
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


 
Reply With Quote
 
Thomas J. Gritzan
Guest
Posts: n/a
 
      08-01-2006
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
 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      08-01-2006
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


 
Reply With Quote
 
Daniel T.
Guest
Posts: n/a
 
      08-01-2006
In article <(E-Mail Removed) .com>,
"Siam" <(E-Mail Removed)> 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?
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
private member function or non-member utility function ittium C++ 5 01-12-2012 08:56 AM
What are the naming convention for private member variable, andprivate and public member function? Peng Yu Python 3 09-21-2009 04:49 AM
Error When using Crystal Reports: 'C' is not accessible in this context because it is 'Private'. Richard ASP .Net 1 07-27-2004 07:03 AM
Procedure not accessible when private in webform Tim Zych ASP .Net 3 05-12-2004 02:40 AM
ProcessModelConfig' is not accessible in this context because it is 'Private' Jack Wright ASP .Net 3 01-05-2004 03:58 PM



Advertisments