Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!rutgers!apple!motcsd!hpda!hpcuhb!hpcllla!hpclisp!hpclscu!shankar
From: shankar@hpclscu.HP.COM (Shankar Unni)
Newsgroups: comp.lang.c++
Subject: Re: Re^2: information hiding
Message-ID: <1000017@hpclscu.HP.COM>
Date: 30 Jun 89 01:02:25 GMT
References: <1827@itivax.iti.org>
Organization: Hewlett-Packard Calif. Language Lab
Lines: 32

> Actually, it would have been very easy to design C++ in such a way that the
> private data of a class didn't need to be specified in the class
> definition: represent each class object as a pointer to the real object.

$DRIFT ON$

Actually, there are two aspects to hiding information: the first could be
simply to prevent the programmer from looking at the class internals.

Another is to be able to minimize recompilation every time the
implementation of some reusable class is changed. After all, the interface
has not changed, so there is no reasonable reason for the callees to
"change".

It is certainly possible to implement such a scheme for the current
definition of the language using pointers as described above. The compilers
would completely ignore (for storage allocation purposes) the private
parts, and the constructors would be responsible (this could be done
automatically by the compiler) for allocating space for the private parts
and virtual tables and all that cruft. In a rapid-prototyping environment,
might even be a very desirable thing (if I change the internals of a class
in a small way, I only want to relink my applications, not recompile all of
them each time).

The cost for this is a slowdown of the executable, but in such
environments, this would be acceptable. After all, it is always possible to
have a "production run" of the compiler to produce "efficient" code.

$DRIFT OFF$
---
Shankar Unni                                E-mail:  shankar@hpda.hp.com
Hewlett-Packard California Language Lab              ...!hplabs!hpda!shankar