Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!hp-pcd!hplsla!jima
From: jima@hplsla.HP.COM (Jim Adcock)
Newsgroups: comp.lang.c++
Subject: goodbye cpp ???
Message-ID: <6590072@hplsla.HP.COM>
Date: 15 Nov 88 19:46:27 GMT
Organization: HP Lake Stevens, WA
Lines: 56

As we head towards parameterized classes, isn't it time to
start thinking about getting rid of cpp, and its associated
non-syntactic hacks, and the compile/link inefficiencies
it introduces?

The big remaining issue I haven't seen addressed in C++
that would be necessary to get rid of cpp is finding
an equivalence to "#include an-import-definitions-file",
and "an-export-definitions-file.h"

Other language implementations I am familiar with address
this issue by adding an "import such-and-such-a-library"
declaration instead of the "#include such-and-such" and
adding an "export { such-and-such-definitions }" section
instead of using a .h file.  The "exported" definitions
get "compiled" and included in the .o file.

I'm NOT saying that putting the exported definitions in
the .o file is "the right way to go" -- for example alternatively 
a compiler could automatically generate a .h file and stick
it in an appropriate place as the mechanism for "exporting"
definitions.

[Clearly since the compiler now understands whether "library
 such-and-such" has been defined or not, multiple #include
 issues go away, as well as issues of how a particular human
 being should manually organize their .h files for maximal
 "efficiency."  These become issues for compiler writers
 to handle ONCE [per compiler] rather than compiler users
 having to address the issues ad-infinitem]

What I AM saying is: can't we get rid of cpp?  And incorporate
the remaining commonly used "features" of cpp in the language?
Even if one has an integrated program development environment,
wouldn't one still want a unit of program development work
analogous to the present "file" as a compilation unit, and
wouldn't one still want a hierarchical naming convention for
specifying what "libraries" one wants to build this unit
of program development effort [file] on top of?  Using 
"aClassName" to specify what "unit-of-development-effort"
[library] to build your development-effort on top of
doesn't seem like a good idea to me since everyone who
develops a library seems to believe their base class
is "the way to go" and therefor either names it "object"
or "Object."  So if one wants to use Joe's library and
Sue's library one needs to be able to differentiate
whose "object" class one wants to build a particular class 
on top of.  ???

Once we had these kind of features in the language, then
cpp could be a compiler option that one could either
turn on or off, and one wouldn't be forced to write
"hack" code, and better "linters", "pretty-printers",
etc, could be developed.....

Comments?