The GCC Project has just updated its front page with the addition of two significant announcements: support for precompiled headers (PCH) and a new C++ parser that has brought g++ near the top of the food chain in conformance and led to over 100 bugs being closed.
GCC on MacOS X uses precompiled headers and it makes a huge difference in compile time. Glad to see the FSF is finally taking this into thier implementation.
That’s a neato Feature. The Headers get compiled once. This is a lengthy process (was on BeOS, is on X), but once it’s done your average project compile flys.
—
http://homepage.mac.com/softkid
I am not spoiling the fun, just citing a mail that followed up the “100 bugs closed”:
> At some point, not to far in the future, perhaps when
> phase 2 of GCC 3.4 starts or even now, we should send
> an note to gcc-announce with mentioning the new parser
> and that 3rd party projects should start fixing their
> code bases.
> (I would be very surprised if this doesn’t affect
> nearly every single non-trivial free software package
> written in C++ out there.)
Don’t you just love it when people *assume* that the compiler will always be the same, and have to “fix their code bases” when a new compiler version arrives? 😉
Wow, Apple is doing a lot for Open Source these days
Thank you Apple, Red Hat and CodeSourcery!
According to the manual, the precompiled header allows only a single precompiled header per compilation. Ooops. How is this supposed to work? Use ugly hacks like “all.h” which includes all headers that an app may need? Eeehhhh…
Don’t you just love it when people *assume* that the compiler will always be the same, and have to “fix their code bases” when a new compiler version arrives?
This seems to be the case with a great deal of software, which is far from C89 compliant. I prefer not to assume that a compiler supports more than C89… and personally I think C89 compliant code seems a lot less messy than code written around newer standards.
Will gcc 3.3 incorporate these additions or will we have to wait until gcc 3.4?
What gcc really needs is a non-bison parser. Then we’re REALLY be in business. Sorry, maybe its just a personal thing but I find it hard to believe that C optimised specifically for the purpose (gcc) isn’t faster than C optimised for generic purposes (bison output).
will be in gcc 3.4
> What gcc really needs is a non-bison parser….
Well, that’s what the new C++ parser is: hand-coded recursive descent. And the author of the new front end agrees that it probably will be faster than the bison-generated parser. But the real benefit (IMHO) is eliminating the need to understand the complex interactions between the lexical analyzer, parser, and later stages of the compiler that naturally result from using a generated parser with a complex (i.e. ambiguous) grammar like that of C++.
No, it doesn’t say it “only a single precompiled header per compilation.”
From the page you are talking about:
“To create a precompiled header file, simply compile it as you would any other file, if necessary using the -x option to make the driver treat it as a C or C++ header file. You will probably want to use a tool like make to keep the precompiled header up-to-date when the headers it contains change.”
“A precompiled header file will be searched for when #include is seen in the compilation. As it searches for the included file (see Search Path) the compiler looks for a precompiled header in each directory just before it looks for the include file in that directory. The name searched for is the name specified in the #include with .pch appended. If the precompiled header file can’t be used, it is ignored.”
so if you #include <stdio.h> and #include <stdlib.h>, it will search for stdio.pch, then stdio.h, then stdlib.pch, then stdlib.h when you compile that C file.
For some reason, they use “all.h” as an example header file, but they do not say that all headers must be contained within that one file.
Any ideas when 3.4 stage 1 starts?