Re: C include handling, was Bison deterministic LALR

Marco van de Voort <marcov@toad.stack.nl>
Wed, 5 Sep 2012 08:40:43 +0000 (UTC)

          From comp.compilers

Related articles
=?UTF-8?Q?Bison_determinis=E2=80=8Btic_LALR=281=29_parser_for_Java=2FC hsad005@gmail.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 anton@mips.complang.tuwien.ac.at (2012-08-20)
Re: Bison =?UTF-8?B?ZGV0ZXJtaW5pc+KAi3RpYyBMQUxSKDEpIHBhcnNlciBm?= =?U cr88192@hotmail.com (BGB) (2012-08-21)
=?UTF-8?Q?Re:_Bison_determinis=E2=80=8Btic_LALR=281=29?= =?UTF-8?Q?_pa bc@freeuk.com (BartC) (2012-08-22)
Re: Bison =?UTF-8?B?ZGV0ZXJtaW5pc+KAi3RpYyBMQUxSKDEpIHBhcnNlciBm?= =?U cr88192@hotmail.com (BGB) (2012-08-26)
Bison deterministic LALR parser for Java/C++ bc@freeuk.com (BartC) (2012-08-29)
Re: C include handling, was Bison deterministic LALR marcov@toad.stack.nl (Marco van de Voort) (2012-09-05)
| List of all articles for this month |

From: Marco van de Voort <marcov@toad.stack.nl>
Newsgroups: comp.compilers
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 <bc@freeuk.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
> likes.


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
accordingly.


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]



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.