Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!exodus!rbbb.Eng.Sun.COM!chased
From: chased@rbbb.Eng.Sun.COM (David Chase)
Newsgroups: comp.lang.c++
Subject: Re: Problems maintaining header files
Message-ID: <7091@exodus.Eng.Sun.COM>
Date: 31 Jan 91 19:23:13 GMT
References: <15917@reed.UUCP> <6107@stpstn.UUCP> <486@eiffel.UUCP> <1466@acf5.NYU.EDU>
Sender: news@exodus.Eng.Sun.COM
Organization: Sun Microsystems, Mt. View, Ca.
Lines: 59

In article <1466@acf5.NYU.EDU> sabbagh@acf5.NYU.EDU (sabbagh) writes:
>bertrand@eiffel.UUCP (Bertrand Meyer) writes:
>
>>	For that matter, with Eiffel there is no need for header files
>>or make files of any kind. The compiler takes care of analyzing
>>dependencies (by analyzing the source text, which is where the
>>information is, and the only place where it should be) ...

>Unfortuantely, Dr. Meyer has committed the one great sin of academia: he
>has become religious about a single idea.  Here's why the software profession
>can't move to the 1990's:
> [remarks directed against Eiffel deleted]

I think you have missed the point; these features need not be unique
to Eiffel.  Granted, Meyer takes a more extreme position (analyze the
source text) than I do, but "header files" that are something merged
into the source text by a pre-processor are really not a very good
idea.  Separate interface files in the style of Mesa and Modula are
much more useful.  They permit easy design and implementation of
language-based tools that (in C, at least) are usually handled by
creation of yet-another meta-language (for example, Mig).  Makefiles
are unnecessary.  Data marshalling routines can be created by a
language-based tool.  (One can decide, after the fact -- "hey, I'd
like to store this data, pointers and all, on disk", and get the job
done by using a simple tool, instead of having to write a
meta-language description of the existing data structures for
processing by some other tool.)  Stub generators are another
language-based tool.  I'm not saying that these things are imposible
for C/C++, but for an interface-based language they are far far
easier.

In C++, people I know have complained about multiple copies of virtual
function tables created by declarations included in multiple files,
and have proposed a pragma to deal with this.  For a language with
designed-in "interface" files, no such problem exists (rather, it is
up to the implementation to deal with this).  For C++, pre-compiled
header files are regarded as a new and interesting problem to be
tackled; for Mesa, Modula, and their derivatives, this problem has
been solved for years.  Other approaches include compiler servers that
cache interface files for re-use.

I suppose I'm preaching to the unconvertable, but it seems unusual
that someone would damn a language feature that they haven't tried.
I've tried both, and I know which one I like better.

Note, too, that in the system I used (Modula-3) we did make use of the
pre-processor from time to time, but only for those things where it
was the most appropriate tool (e.g., OS-dependent changes to data
structures, not simulating interfaces by file inclusion).  We had a
stub generator, a data marshalling generator, a makefile generator
(because we didn't really feel like duplicating the entire function of
make), a compiler server (that cached interface files for subsequent
compiles), consistency checkers, a C-generating compiler, and an
interpreter.  We used our tools to build new tools, and we were very
productive.

David Chase
Sun (all the Modula-3 work took place at Olivetti over a period of
about 2 years)