? (0xe2.0x9a.0x9b@gmail.com) on 6/28/10 wrote:
>
>For example, I don't understand why don't you fully admit
>that current C/C++ compilers did not really embrace the
>idea of "precompiled header files". They started to support
>it long time ago - but then stopped in half-way of the
>process. So, what we have now is some *mediocre* (at best)
>implementation of this idea.

The thing is, precompiled header files really are very
hard to do right for C/C++. The semantics of a C header
include are not simply very amenable to doing it. It's
entirely possible - and quite common - for a header file
to totally change depending on some random preprocessor
symbol.

And even if you handle that issue (by versioning all the
precompiled headers by all the preprocessor symbols they
depend on), you still don't solve the problem: because
even in the absence of those kinds of big and obvious
textual context changes, you still end up having all the
subtle type issues where a type in a header file will
depend on types declared earlier in other places.

The fact is, the C header files are very much inherently
designed to be about textual expansion, not about some
notion of "interface" that you include. So the only simple
kind of precompilation you can do is to pre-parse the thing
(tokenization, comment removal etc), anything else is very
complicated indeed.

And don't get me wrong. "very complicated" doesn't mean
"impossible". It's been done, but almost every time it has
been done, it has resulted in either (a) nasty bugs where
the precompilation infrastructure means that the compiler
doesn't really follow C/C++ semantics or (b) not noticeably
faster compile times, because the added complexities add
enough overhead and the win isn't sufficiently large (which
is usually because the precompilation does mainly some
pre-tokenization, so the win simply isn't huge).

The thing is, you can get fast compile times, but
the way to do so is to keep your headers simple and clean.
And not have some spaghetti of headers including other
headers.

But that is hard, and requires insane amounts of effort.
It's hard even with plain C, and it tends to be harder
still in C++, if only because you end up having even more
complicated headers for the templates etc.

Which is why usually people resort to parallel builds. That
usually requires a fair amount of effort too, and seldom do
you see really well parallelized build environments. But
you can usually get a fairly good speedup reasonable easily
without spending an inordinate amount of time on it.

Still - even for "just" parallel builds, getting all the
dependencies right, and avoiding lots of serialization
points, can be quite hard. In a big project (and that's
when it matters most) you usually try to have subprojects
with independent makefiles etc. And when one of them is a
library that some other part depends on, it's usually not
all that trivial to build the two parts in parallel.

There is a reason why other languages try to not do the C
or C++ kind of preprocessor. They tend to try to specify
dependencies not as text replacement, but as "interface
definitions". That avoids a lot of the complexities with
precompiling the headers.

Linus