|=?UTF-8?Q?Bison_determinis=E2=80=8Btic_LALR=281=29_parser_for_Java=2FC email@example.com (2012-08-17)|
|Re: Bison =?UTF-8?B?ZGV0ZXJtaW5pc+KAi3RpYyBMQUxSKDEpIHBhcnNlciBm?= =?U DrDiettrich1@aol.com (Hans-Peter Diettrich) (2012-08-18)|
|Re: Bison =?UTF-8?B?ZGV0ZXJtaW5pc+KAi3RpYyBMQUxSKDEpIHBhcnNlciBm?= =?U firstname.lastname@example.org (2012-08-20)|
|Re: Bison =?UTF-8?B?ZGV0ZXJtaW5pc+KAi3RpYyBMQUxSKDEpIHBhcnNlciBm?= =?U email@example.com (BGB) (2012-08-21)|
|=?UTF-8?Q?Re:_Bison_determinis=E2=80=8Btic_LALR=281=29?= =?UTF-8?Q?_pa firstname.lastname@example.org (BartC) (2012-08-22)|
|Re: Bison =?UTF-8?B?ZGV0ZXJtaW5pc+KAi3RpYyBMQUxSKDEpIHBhcnNlciBm?= =?U email@example.com (BGB) (2012-08-26)|
|Bison deterministic LALR parser for Java/C++ firstname.lastname@example.org (BartC) (2012-08-29)|
|Re: C include handling, was Bison deterministic LALR email@example.com (Marco van de Voort) (2012-09-05)|
|From:||Marco van de Voort <firstname.lastname@example.org>|
|Date:||Wed, 5 Sep 2012 08:40:43 +0000 (UTC)|
|Organization:||Stack Usenet News Service|
|References:||12-08-005 12-08-006 12-08-009 12-08-014 12-08-015 12-08-018 12-08-020|
|Keywords:||C, parse, performance|
|Posted-Date:||05 Sep 2012 05:58:21 EDT|
On 2012-08-29, BartC <email@example.com> wrote:
>> another issue is that things like precompiled headers are non-standard,
>> and there is no real agreed-on convention for "hey, compiler, feel free
>> to use precompiled headers here".
> Why should how a compiler optimises its work violate the standard?
> Provided the end results are the same, the compiler can do what it
True, but that is a complex problem, since processing a header starts
with a preprocessor state (at the point of including), then processing
it changes compiler and preprocessor state.
I'm not a C expert, but it probably depends on the state of the
compiler on inclusion too (e.g. when you can check if a type is
already defined or not)
Both the output states are dependent on (both) the input state which
in turn depend on the point of inclusion.
So precompiled headers should probably reduce the input state to the
bare essentials, and reduce the changes to the output change
Then one should be able to check if the reduced input state matches the one
in the precompiled header before it is loaded.
>> AFAIK, the preparsed/precompiled headers for C generally handle #if and
>> #ifdef and similar during the preprocessor as usual. this seems to be a
>> large part of why there are many restrictions on the use of precompiled
>> headers in those compilers which support them.
>> AFAICT, languages like C# delay commands like #if or #ifdef until later
>> (and impose restrictions on how they may be used). IIRC, they are
>> generally handled at linking or at JIT.
Or they use a different way of importing that zaps
preprocessor/compiler state to some known global state, and doesn't
allow code before #include, removing the dependency on compiler state.
[The preprocessor conceptually happens before the parse, so
preprocessor state doesn't depend on compiler state. But #if means
that the sequence of includes affects both the preprocessor state and
the compiler state. -John]
Return to the
Search the comp.compilers archives again.