|speeding up compile times in C++ firstname.lastname@example.org (1995-01-26)|
|Re: speeding up compile times in C++ email@example.com (1995-01-26)|
|Re: speeding up compile times in C++ firstname.lastname@example.org (1995-01-29)|
|Re: speeding up compile times in C++ email@example.com (1995-02-02)|
|Re: speeding up compile times in C++ firstname.lastname@example.org (Steve Glass) (1995-02-03)|
|Re: speeding up compile times in C++ email@example.com (1995-02-04)|
|Re: speeding up compile times in C++ firstname.lastname@example.org (Ronald F. Guilmette) (1995-02-04)|
|Re: speeding up compile times in C++ email@example.com (1995-02-06)|
|Re: speeding up compile times in C++ firstname.lastname@example.org (Anthony T. Green) (1995-02-06)|
|Re: speeding up compile times in C++ email@example.com (1995-02-08)|
|Re: speeding up compile times in C++ firstname.lastname@example.org (1995-02-12)|
|From:||"Steve Glass" <email@example.com>|
|Date:||Fri, 3 Feb 1995 18:21:48 GMT|
firstname.lastname@example.org (Amir Michail) says:
>Would this idea work? Would it improve compilation times?
Guy L. Winterbotham <email@example.com> writes:
> For a commercial slant on this idea look at Borland C++ which makes use
> of precompiled headers. As long as you can keep the .h files needed
> by your project to a known set it makes a hugh difference to compile
and Taylor Hutt <firstname.lastname@example.org> writes:
> Why is it that the concept of a symbol file is so hard for C++ programmers
> to understand? This problem has been solved for quite a long time with
> languages using a real module structure yet, despite this fact, C++
> programmers and writers continually propose new solutions ranging from
> wrapping anonymous structure pointers (read: opaque types) in the main
> header file (so the implementation can be changed at will) to the idea
> proposed here.
Well, our project is nearly 1 million lines of C++. We have thousands of
classes but only use `standard' C++ techniques (not including headers
whenever possible, using forward declarations etc.) and do not use
`clever' declaration techniques such as opaque types.
We too have hit the dumb compiler/language problem. Our cfront compiler
spent most of the *very* long build process contructing symbol tables for
included classes. So, we did an experiment:
Rather than separately compile individual files and then link into a
library or program we used the preprocessor. We #include all the sources
for a library into one source file and compiled that as a whole.
The purpose of this approach is to ensure the compiler reads a class
declaration once only. The result? Compile/link times were cut to 1% of
those using the conventional separate compilation/linking approach.
However, there are potential problems, the possible quiet redefinition of
macros and a change in the meaning of static (which essentially becomes
extern since `file' scope is now the whole lib/program).
Since we had such significant benefits at very little cost this has become
a key technique for quickly building large libraries. The results
suggests symbol files have many advantages for C++, especially since
parameterised types already require the compiler to hold some information
across separate compilations.
Hopefully, someone out there in cfront land will take note of Taylor's
comments because us C++ users *need* a proper solution and not yet another
Return to the
Search the comp.compilers archives again.