Mail Archives: djgpp/1997/06/26/07:34:34
Salvador Eduardo Tropea (SET) writes:
>You'll see that cpp is fast in comparisson with cc1plus. Now you can
>say: But it will speedup the cpp part and a 10% is usefull. For that
But precompiled headers cut out a lot more than just the cpp stage! They
are a dump of already-parsed symbols and function tokens (for a gcc
implementation, I presume this would be something like the RTL
description for the compiled code). So you are removing not only the
preprocssing stage, but a lot of tokenising and syntax parsing work from
the compile stage as well.
This is obviously a tricky thing to implement in a reliable way: the
usual approach (at least in Visual C) seems to be to allow one
precompiled header per program (usually stdafx.h) and require it to come
at the very top of the file. You give a command line option to the
compiler telling it which file this is, and when it sees a #include
"stdafx.h" it will look for a file called stdafx.pch, which contains a
dump of the parsed file contents left over from a previous
compilation...
>I guess it works very well for Borland compilers because the preprosses
>part is equally fast than cpp but the real compiler is much more faster
>so the percent is greater.
I think the point is that Windows programs, particularly ones that use
libraries like MFC or OWL, include an obscene amount of header files,
and these are mostly C++ code which contains a lot of complex class
definitions. MFC has about 200k of headers: that takes a long time to
parse! In a properly designed system you don't need that amount of crap
before you can start writing real code, so precompiling the headers
isn't so much of an issue...
--
Shawn Hargreaves - shawn AT talula DOT demon DOT co DOT uk - http://www.talula.demon.co.uk/
Beauty is a French phonetic corruption of a short cloth neck ornament.
- Raw text -