Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.misty.com!news.iecc.com!.POSTED!nerds-end From: Marco van de Voort Newsgroups: comp.compilers Subject: Re: C include handling, was Bison deterministic LALR Date: Wed, 5 Sep 2012 08:40:43 +0000 (UTC) Organization: Stack Usenet News Service Lines: 44 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <12-09-006@comp.compilers> References: <12-08-005@comp.compilers> <12-08-006@comp.compilers> <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> NNTP-Posting-Host: news.iecc.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: leila.iecc.com 1346839101 53203 64.57.183.58 (5 Sep 2012 09:58:21 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Wed, 5 Sep 2012 09:58:21 +0000 (UTC) Keywords: C, parse, performance Posted-Date: 05 Sep 2012 05:58:21 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:742 On 2012-08-29, BartC 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]