dlw@odi.com (Dan Weinreb) (08/12/89)
As Andrew Koenig pointed out in his reply, my earlier posting was
somewhat confused. Sorry, I'll try to be more careful in the future.
Here is a better (tested!) example of the principle that C++ access
control does not truly and completely hide variable names.
Suppose that a library-writer has provided a base class. Now I would
like to make my own derived class, based on this base class. The
names that the library-writer chose for his own internal variables
ought to be hidden from me. That is, my own derived class ought to
work no matter what names the library-writer used for his private
variables. (At MIT, this was called "referential transparency".) Now
consider this example:
/* The base class was written by the library-writer. */
class base {
private:
int q;
};
/* Everything below this point was written by me, the application
writer. */
class derived : public base {
int func();
};
extern int q;
int derived::func() {
return q;
}
Cfront 2.0 responds with the following error message:
"visib.C", line 13: error: derived::func() cannot access base::q: private member
This error message only came up because I happened to choose the same
name for my external variable as the library-writer chose for his
internal private variable. So his choice was not hidden from me.
Please note that I am not trying to make a simplistic, blanket
criticism of C++. While I do think that referential transparency is a
good thing, I appreciate that there are many tradeoffs in language
design, and that a variable-scoping rule that provided referential
transparency might introduce new and different problems, or greater
complexity somewhere else in the language design. I just think it's
important for C++ programmers to have a good understanding of the
rules of C++ variable scoping and access control, so that they can
use the language more effectively.
Dan Weinreb Object Design, Inc. dlw@odi.com