Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!sharkey!itivax!scs
From: scs@itivax.iti.org (Steve C. Simmons)
Newsgroups: comp.lang.c++
Subject: Re^2: information hiding
Message-ID: <1827@itivax.iti.org>
Date: 27 Jun 89 15:44:17 GMT
References: <6031@watdcsu.waterloo.edu> <6590164@hplsla.HP.COM> <1421@cbnewsc.ATT.COM> <7709@spool.cs.wisc.edu>
Organization: Industrial Technology Institute, Ann Arbor, MI.
Lines: 30

solomon@gjetost.cs.wisc.edu (Marvin Solomon) writes:

>The trouble is that a class definition serves two purposes:  to document
>the class interface to a human user and to provide a compiler with enough
>information to compile a client of the class.  The private members are
>superfluous (indeed, it could be argued they are harmful) for the former
>purpose, but essential for the latter . . .

Solomon goes on to detail his arguement, see the original if you like.

If you really wanted to, it would not be particularly difficult to
completely hide the private interface under UNIX.  Put the public
parts in as you would normally, but place private in a separate file/dir,
eg,
 #include	"/usr/include/c++private/your_class_here"
Now make a new group, make the /usr/include/c++private directory and
contents of that group, and make the appropriate c++ utilities sgid
that group.  Permit /usr/include/c++private 750, and you have a hidden
area the compiler can see but users cannot.

On the other hand, I would argue there is little to gain by hiding such
from the programmer.  By reading the private parts of the declaration
one can get a better understanding of what the class really does.  It
helps nail down subtle performance things that might not be in the
(probably non-existant) class documentation.  Since the compiler does
a pretty good job of enforcing privacy, the risks are very minor.
-- 
Steve Simmons		          scs@vax3.iti.org
Industrial Technology Institute     Ann Arbor, MI.
"Velveeta -- the Spam of Cheeses!" -- Uncle Bonsai