Path: utzoo!utgpu!watmath!clyde!att!rutgers!ucsd!sdcsvax!ucsdhub!hp-sdd!hplabs!hp-pcd!hplsla!jima
From: jima@hplsla.HP.COM (Jim Adcock)
Newsgroups: comp.lang.c++
Subject: Re: goodbye cpp ??? (macros vs. inline functions)
Message-ID: <6590075@hplsla.HP.COM>
Date: 29 Nov 88 18:08:50 GMT
References: <3637@pt.cs.cmu.edu>
Organization: HP Lake Stevens, WA
Lines: 25

> In other words, with new constructs that will have to resemble #include
> in many ways, except that they will undoubtedly be more complex.  Why bother?

Well, for one thing, people are publishing long articles on notes on
how to fine tune (by hand) .h files so that you can compile c++ programs in a 
reasonably finite amount of time.  Why not let the compiler figure out these
"optimizations" for the user?  Also if .h files were kept around in "compiled"
form, there could be time savings over recompiling this code whenever the
class is used by another class.

Also, the .h separation from the .cc file [or whatever extension you use]
is just not a natural way to program -- far better to have your class
definitions up front in an export section, followed by your functions.

As long as there is .h files you cannot do true data hiding of the 
implementation.

Presently compilers have no way of knowing what is really export material
verses import material, so that multiple vtables get generated.  Of course
you can prevent this with a compile time option -- another hack.

Finally, is not specification of which classes you really want to build
your classes on top of really part of the language?  If so, why not
recognize this, why force a hack into every .cc file, every class that
gets written?