i don't think anybody else undestands this method of coding either.
precompiling headers as a performance hack is akin to this kind of thinking:
patient: doctor, doctor it hurts when i do this.
doctor: i think you need a special brace. there's a specialist for
these
kind of problems. let me write you an order...
instead of
patient: doctor, doctor it hurts when i do this.
doctor: don't do that then.
to amuse yourself. try this.
; gcc -E somefile.c
; wc -l somefile.i
this is especially fun on a glibc machine. but code like this is not the reason
gcc is so slow.
try tcc, lcc, or icc on the same source code.
- erik
p.s. i've got to say one thing in gcc's favor. it was way the heck better than
any other compiler i had available when it was first written. it actually did
prototypes and warned if things didn't match. i guess it's been all downhill
since gcc-1.38
On Sat Mar 25 19:47:10 CST 2006, [EMAIL PROTECTED] wrote:
> I find the notion of pre-compiled headers for anything other than
> a very special situation rather odd. Although the example given in
> the link is trivial it demonstrates an unthinking inefficiency we
> see all too often in practice:
>
> there's a file foo.c which has an accompanying file foo.h which
> is only ever included in foo.c
>
> This is a poor idea in many ways and is perhaps one of the reasons
> we see all these other things being necessary to make the user believe
> that things are happening faster.
>
> Recently I was poking around in a multi-file open source driver and
> came across more than one instance of the following which pulled me
> up short (names changed to protect the guilty):
>
> foo.h contains the following:
>
> #define THING { \
> { 1234, XXX_YY0, ZZZ0 }, \
> { 5678, XXX_YY1, ZZZ1 }, \
> ... 200 more of these ...
> }
>
> and is only included in foo.c which contains one instance of
> its use:
>
> static const struct
> thing thing_table[] = THING;
>
> It would never occur to me to #define a table like that. Age, I
> suppose.
>
> --jim
