Path: utzoo!attcan!uunet!husc6!bloom-beacon!mit-eddie!uw-beaver!uw-june!david
From: david@june.cs.washington.edu (David Callahan)
Newsgroups: comp.lang.c++
Subject: Re: Can we hide the private part of a class ?
Message-ID: <5922@june.cs.washington.edu>
Date: 3 Oct 88 19:43:52 GMT
References: <1358@stratus> <1988Sep29.044111.16104@utzoo.uucp> <4193@polya.Stanford.EDU> <1988Oct2.045604.17456@utzoo.uucp>
Reply-To: david@uw-june.UUCP (David Callahan)
Organization: U of Washington, Computer Science, Seattle
Lines: 29

In article <1988Oct2.045604.17456@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>In article <4193@polya.Stanford.EDU> shap@polya.Stanford.EDU (Jonathan S. Shapiro) writes:
>>The flip side of this is that what you say about both languages is
>>wrong given a good librarian. ...
>
>Um, no, it doesn't eliminate the dependencies, it just hides them.  If
>you change the size of something, everything that knows about it still
>has to be recompiled. ...

Changing the size or position of private elements changes only the 
offsets of the public elements. These could be treated as external 
variables and bound at link time rather than compile time. There might
small performance penalty if a particular architecture handles small
offsets better than big ones and the compiler must assume a big offset.
This goes for sizeof() too.

>Remember, too, that sizes are the easy part -- things like inline functions
>are both more significant and harder to do.
>-- 
>The meek can have the Earth;    |    Henry Spencer at U of Toronto Zoology
>the rest of us have other plans.|uunet!attcan!utzoo!henry henry@zoo.toronto.edu

Inline functions are real compilation dependences and can not be hidden by late
binding, but the orginal poster's intent was to hide implementation details, 
not avoid recompilation when public information changes, 
and that is certainly posible.


David Callahan