🚀 go-pugleaf

In article <1590@crash.cts.com>, elund@pro-graphics.cts.com (Eric Lund) writes:
> > I'm concerned that such a compiler would be bigger and probably
> > slower than a C-only compiler. In other words, I want
> > the best, smallest, fastest C compiler Borland can
> > make. Although I'm not interested in C++ I know that many other
> > people are and that's why Borland should include 2 compilers
> > in TC3.0, a C only compiler and a C++ compiler that presumably
> > will also compile C.
> 
> Borland's C compiler is currently the fastest (in compile times) on the
> market.  I, for one, am interested in learning C++.  However, I agree with
> your concern over loss of speed.  I have faith in Borland they will produce
> an efficient compiler, and integrate the two well.

I don't know anything about C++ (haven't had time to look at it),
so I'm speaking from partial ignorance.  But what interests me is why
everyone seems to think that a compiler that accepts both languages
_must_ be slower even when compiling a program using just C.  Obviously 
you can (at the cost of significant memory) have a compiler switch which
compiles one language or the other, calling the appropriate semantic
analysis routine;  the difference in speed shouldn't be noticeable,
except for the extra amount of time to load the other analysis routine
from disk.

If the languages are closely related, which I gather C and C++ are,
a single semantic analysis routine might be able to handle programs 
written for both languages.  The major reason I can think of for the
compiler to be noticeably slower in this case would be if the C++
language requires a greater computational complexity in the parsing
and semantic analysis routines.  (For example, when Ada was first
introduced, nobody knew any algorithms for doing a semantic analysis
that ran in less time than O(N**3), where N is the number of terminals.
This is caused by Ada's overloading of operators and identifiers; most
languages require only O(N) time.  It is now known that algorithms 
exist which can analyze Ada in O(N) time, but this is not guaranteed 
for all languages).

Obviously there might be a significant _run-time_ hit if a combined
compiler had to do a lot of run-time interpretation (say because the
C++ language allowed manipulation of the program source text at run
time, although there are often ways to greatly reduce the burden of
having to interpret the code from scratch every time).  Or in this
sort of case there might be a possibility of maintaining the original
run-time speed if analysis indicated that only C language constructs 
were used, but this _could_ increase compilation time.

A lot of compilers can be thought of as an enormous loop of the form:

		while (!eof) do	{
			switch ()	{	...
				}
			}

where (modulo the amount of time to load the extra code from disk)
you can add lots of additional constructs without making much of a
difference in compilation speed.  The exceptions are languages like
Ada (above) which may require a lot of backtracking in order to do
the parse or the semantic analysis.  (it's true that a compiler
back end often does operate with backtracking but presumably the
back end would be pretty similar to that of a C only compiler ... 
or at least that portion of the back end that would be used in the
compilation of a program only using C constructs).

Is C++ really harder to parse than Ada?  Or are the concerns more
about run-time efficiency than about compilation efficiency (and why
would C++ be so bad)?  Or are people mostly just worried about the
disk space (which I can certainly sympathize with)?

As I said, I don't know anything particular about C++ besides things
I've seen on the net and the trade rags.  Could someone enlighten me?

						Bruce C. Wright