Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!gatech!cumulus!hsu
From: hsu@cumulus (Yung-Kao Hsu)
Newsgroups: comp.lang.c++
Subject: Re: Can we hide the private part of a class ?
Keywords: header dependency, efficiency.
Message-ID: <1368@cumulus>
Date: 2 Oct 88 20:37:00 GMT
References: <1358@stratus> <1988Sep29.044111.16104@utzoo.uucp> <4193@polya.Stanford.EDU>
Reply-To: hsu@cumulus.UUCP (Yung-Kao Hsu)
Organization: Georgia Institute of Technology
Lines: 64

---------

In article <1988Sep29.044111.16104@utzoo.uucp> henry@utzoo.uucp
(Henry Spencer) writes:

>In article <1358@stratus> hsu@stratus (Yung-Kao Hsu) writes:
>>This features make package/module interfaces cleaner (you don't see any
>>implementation information at all), and there are more advantages.
>>But, I couldn't find anything similiar in C++ !!
>
>The user can't access x, so seeing it won't do him much good.  However,

This is true if all public functions won't return any pointer to x.
But, sometimes for efficiency reason, we will allow such bad pratice.

For example, if x is a table whose element is defined as an union of 5
different data types and there are 5 different classes that defined to
handle these data types. Since the main function for the object containing
x is record keeping, pointers seems to be the best choices for both efficiency
and program readability in designing the interfaces between these classes.

But, since we can see the definition and with pointers, nothing is safe.
Anyway, I agree that what you said in general is right.

In article <1988Sep29.044111.16104@utzoo.uucp> henry@utzoo.uucp
(Henry Spencer) continues:
>the compiler now knows exactly how big a variable of class X is, so it
>can generate code that knows this.  If those private declarations were
>hidden somewhere else, either the compiler has to get much more complex
>or else class variables can't be as efficient as ordinary variables.
>For example, as I recall (it's been a while...), since Modula 2 doesn't
>tell the compiler how big the variable is, all the compiler can do for
>space allocation is to allocate a pointer to the variable, and do all
>accesses via that pointer.

In article  <4193@polya.Stanford.EDU>  shap@polya.Stanford.EDU
(Jonathan S. Shapiro)replied:

: All of what you say is true and good, and I think the tradeoff is
: worth it, but it is worth pointing out on the other side that a
: consequence of unifying the private and public parts of the code are
: an increase in the header dependencies that can get explosive.
: Consider having a private member of type froboz.  Even if there is no
: public member of type froboz, all of the includers of the class
: definition have to know what a froboz is - EVEN though they can't make
: any use of the relevant member.

The problem Jon mentioned above was in fact the main reason for my initial
question. I have devloped a very simple compiler in G++ as a framework for
project assignment to be used in compiler course my advisor taught. But, I
simply couldn't write a proper makefile to make seperate compilation
possible. The header dependency simply forces re-compilation of all program
units if some private declarations were changed (which shouldn't cause any
problem to any other classes).

Even though Jon had a semi-solution to this problem, but I think it is
too human-intensive (for undergraduate students at least). Anyway, thanks
to both Jon and Henry for your information.

-- 
YUNG-KAO HSU
School Of Infomation & Computer Science, Georgia Tech Atlanta GA30332
Internet:  hsu@cumulus.gatech.edu	 CSNet:  hsu%cumulus@gatech	
UUCP:  ...!{akgua,allegra,amd,hplabs,seismo,ihnp4}!gatech!cumulus!hsu