Newsgroups: | comp.compilers |
From: | mjr@decuac.DEC.COM (Marcus J. "will do TCP/IP for food" Ranum) |
Keywords: | C, lint, performance |
Organization: | Digital Equipment Corporation, Washington ULTRIX Resource Center |
References: | <19920609091040SEB1525@MVS.draper.com> 92-06-092 |
Date: | Mon, 22 Jun 1992 01:00:03 GMT |
hagerman@ece.cmu.edu (John Hagerman) writes:
>Not quite; you then have a bloated compiler and a bloated linter. I want
>a compiler that screams, and a separate tool (ie, in a different
>executable from the compiler) for checking interfaces, which is only
>needed when an interface changes.
Never mind *that* - I want an interpreter that does dynamic
linking and loading and is reasonably quick; it should reload stuff and
relink stuff blindingly fast, since I program at the tty.
Then my compiler should or can take its own good time, and should
generate blindingly fast code, once I have written it and tested it and
debugged it under an interactive environment.
Compilation is (IMHO) the last step in developing code. I want to
develop in an interactive environment that supports and enhances me as
much as I want - compiling should be relegated to the phase where you are
performance tuning and validating before you ship product. Developing
larger code can be done by developing it a library at a time in the
interactive environment, and then compiling to build the libraries once
they are "done".
This assumes your compiler/optimizer is trustworthy. ;)
mjr.
[We've gotten used to slow compilers, but they can be a lot faster than GCC
and PCC. The DTSS compilers in the mid 70s were so fast that there was no
performance reason to do anything other than completely recompile your program
each time you ran it. -John]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.