Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #742
| From | Marco van de Voort <marcov@toad.stack.nl> |
|---|---|
| Newsgroups | comp.compilers |
| Subject | Re: C include handling, was Bison deterministic LALR |
| Date | 2012-09-05 08:40 +0000 |
| Organization | Stack Usenet News Service |
| Message-ID | <12-09-006@comp.compilers> (permalink) |
| References | (2 earlier) <12-08-009@comp.compilers> <12-08-014@comp.compilers> <12-08-015@comp.compilers> <12-08-018@comp.compilers> <12-08-020@comp.compilers> |
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]
Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar
Bison deterministic LALR(1) parser for Java/C++ (kind of complex langauge) without 'lexar hack' support hsad005@gmail.com - 2012-08-17 11:22 -0700
Re: Bison deterministic LALR(1) parser for Java/C++ (kind of complex langauge) without 'lexar hack' support Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2012-08-18 10:13 +0100
Re: lexer speed, was Bison Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2012-08-20 01:01 +0100
Re: lexer speed, was Bison Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2012-08-20 16:14 +0100
Re: lexer speed, was Bison BGB <cr88192@hotmail.com> - 2012-08-20 14:14 -0500
Re: lexer speed, was Bison Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2012-08-21 07:40 +0100
Re: lexer speed, was Bison "BartC" <bc@freeuk.com> - 2012-08-21 17:39 +0100
Re: Bison deterministic LALR(1) parser for Java/C++ (kind of complex langauge) without 'lexar hack' support anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-20 13:35 +0000
Re: Bison deterministic LALR(1) parser for Java/C++ (kind of complex langauge) without 'lexar hack' support BGB <cr88192@hotmail.com> - 2012-08-21 14:45 -0500
Re: Bison deterministic LALR(1) parser for Java/C++ (kind of complex langauge) without 'lexar hack' support "BartC" <bc@freeuk.com> - 2012-08-22 14:04 +0100
Re: Bison deterministic LALR(1) parser for Java/C++ (kind of complex langauge) without 'lexar hack' support BGB <cr88192@hotmail.com> - 2012-08-26 19:37 -0500
Bison deterministic LALR parser for Java/C++ "BartC" <bc@freeuk.com> - 2012-08-29 22:03 +0100
speeding up C recompilation, was Re: Bison deterministic LALR BGB <cr88192@hotmail.com> - 2012-09-04 13:45 -0500
Re: C include handling, was Bison deterministic LALR Marco van de Voort <marcov@toad.stack.nl> - 2012-09-05 08:40 +0000
Re: Bison deterministic LALR(1) parser for Java/C++ (kind of complex langauge) without 'lexar hack' support hsad005@gmail.com - 2012-08-18 02:09 -0700
csiph-web