"Lorenzo Villari" <vl****@tiscali.it> wrote in message news:<Ta*********************@twister2.libero.it>. ..
The point of data hiding is not to keep you from seeing it. If you're
smart you won't look anyway. The implementation should not concern you --
only interface.
Please explain "If you're smart you won't look anyway"...
The very next sentence answers that:
Any assumptions you make based on what you see in the
implementation just make your own code less maintainable.
Why?
Client code, ie code that _uses_ a class, should know nothing about
how that class works internally. Otherwise, if the internals of the
class change, the client code may no longer work. Which would be a
maintenance problem.
If the client code makes no assumptions about _how_ the class works,
then the internals can change as often and as much as necessary. As
long as the class interface stays the same, the client code will still
work.
This can be achieved through information hiding (making data members
private) and through you taking no interest in how member functions
are implemented when you use a class.
If any data items in a class were not visible to the compiler, it could
not allocate memory correctly. So we do the best we can by declaring all
Then is "this" pointer visible? and the compiler knows anyway you refer to a
variable of a class... without "this" being present
I think you have two issues confused.
The "this" pointer is only used _inside_ non-static member functions
of a class. The code inside a member function can (and probably does)
use private members of its class. But client code that _calls_ the
member function should not know anything about _how_ the member
function does its job.
The point about the compiler allocating memoroy is this. Suppose we
have
// This class defintion could equally well be in a header I included.
class foo
{
public:
int bar();
private:
void private_helper_function();
int private_data;
};
int main()
{
foo a_foo; // Must allocate memory for a_foo.
// some client code that uses a_foo.
int x = a_foo.bar();
return 0;
}
To use class foo, my main function has to be able to see the class
definition for foo, including the private section
(private_helper_function and private_data). But my code can only
actually use the public interface (in this case, just the member
function "bar"). As the programmer, I do not need to look at the
implementation of bar to be able to use the function.
Private members of a class should not concern me when I'm using the
class. So you could argue that having the private members included in
the class defintion my code sees goes against information hiding.
But when I write foo a_foo; the compiler needs to know how much memory
to allocate for the object. The only way the compiler can know that is
to know everything about the class, particularly what data members
(public or private) it contains.
It might be nice from an information hiding point of view if my code
only needed to see the public part of the class definition. But
without knowing that class foo has one int member and no other member
data, the compiler would have no way of knowing how much memory to
allocate when I write foo a_foo;
--
hth
GJD
