Thread: help understanding object scope in C++

Originally Posted by livin4th

the author starts off saying private members cannot be accessed directly by objects of a class and they can only be accessed by member functions.

Perhaps the author meant "objects of other classes". More accurately, if a member of a class is private, then "its name can be used only by members and friends of the class in which it is declared".

Originally Posted by livin4th

In this example, the equalTime() function is using otherClock.hr, otherClock.min etc which is a direct access to private variables of the class object otherClock. I couldn't quite understand his explanation for this. I understand it is from inside a member function but it is another object's private variable directly being accessed here. Can anyone please clarify.

The rationale for having the notion of private access is so that the author of a class can indicate to users of the class that "these are implementation details, don't touch them, and if you do, the compiler will stop and complain". This then allows a future maintainer of the class to change the implementation details without requiring users of the class to change their code (though they may need to recompile).

Who will implement or change the equalTime member function of clockType? Obviously, it is the author or a maintainer of the clockType class. Therefore, it is silly to say that "you cannot access otherClock's private members from equalTime because it is a different object!" because in the end, if the implementation details of clockType changes, it changes for both the current object and for otherClock, hence from within the definition of equalTime, it is fine to access the private members of otherClock.

> private members cannot be accessed directly by objects of a class
Which is basically wrong.

Access to private member variables is ordinarily only via member functions (and friend functions). The functions themselves are not bound to specific instances of the class (you don't get a new copy of the code each time you create an instance of the object).

Anything declared outside the class has to go through the public interface declared for the class.

Your clockType::equalTime can be viewed as
bool clockType::equalTime(clockType *this, const clockType& otherClock) const
Every non-static member function gets 'this' pointer for free, and hr == otherClock.hr is really this->hr == otherClock.hr

You can of course subvert this by writing member functions which return pointers or references to member variables.

Smalltalk disallows objects of the same type from fiddling with each others' private parts. So sad.

Originally Posted by Aslaville

Am guessing this applies to C++ too except may be the part where you have static member, wait, can static variables even be private ?

Actually, the topic of this thread is that it doesn't apply to C++, i.e., that the "private boundary" (to coin a term) is at the class level in C++, not the object level.

I was just mentioning an OOP language where the boundary is at the object level.

And, yes, in C++ static members can be private.

Originally Posted by algorism

Smalltalk disallows objects of the same type from fiddling with each others' private parts. So sad.

Well, it makes sense from a purely theoretical object oriented message passing perspective, but it is just an unnecessary restriction from a practical development and maintenance perspective.