Path: csiph.com!usenet.pasdenom.info!gegeweb.org!news.glorb.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!novia!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED!nerds-end From: "BartC" Newsgroups: comp.compilers Subject: Bison deterministic LALR parser for Java/C++ Date: Wed, 29 Aug 2012 22:03:31 +0100 Organization: A noiseless patient Spider Lines: 68 Sender: johnl@iecc.com Approved: comp.compilers@iecc.com Message-ID: <12-08-020@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> NNTP-Posting-Host: news.iecc.com Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Trace: leila.iecc.com 1346275433 28756 64.57.183.58 (29 Aug 2012 21:23:53 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Wed, 29 Aug 2012 21:23:53 +0000 (UTC) Keywords: C, design, performance Posted-Date: 29 Aug 2012 17:23:53 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com X-Original-Bytes: 4345 Xref: csiph.com comp.compilers:739 "BGB" wrote in message news:12-08-018@comp.compilers... > On 8/22/2012 8:04 AM, BartC wrote: >> But even given all that, there are ways of dealing with huge header files so >> that it is not necessary to repeatedly tokenise and parse the same headers >> over and over again (for recompiling the same module, or compiling many >> modules all sharing the same headers). >> >> I've no idea whether many C compilers actually bother though; perhaps >> it's easier to just recommend a faster computer.. > > the problem here is that, although it isn't too hard to figure out > possible optimizations, it is much harder to make them work in ways > which don't violate the C standard. > > 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. However the C language and the way the C compilers are typically invoked (for example just one-time to compile one module, so it's forgotten it's compiled the same sets of headers a moment before) doesn't make things easy. And it's possible that things such as __TIME__ have been used in such a way that you are obliged to recompile a header each time. So it's easy to see why compilers may not bother! Nevertheless, I think there is plenty that can be done, although I'm not sure that creating intermediate files such as precompiled headers is the way to go. It's better when a compiler is properly integrated into an IDE, then the symbol tables built by a set of headers can be made persistent much more easily. Alternatively, it might be possible to just have a very faster parser! And perhaps integrate the preprocessor so that it is not a separate pass (I haven't attempted a C compiler so not sure if that's feasible; my own source-level directives are handled by the lexer itself, or sometimes by the parser). >> [I've seen C compilers that keep preparsed versions of headers. Dunno >> what they do with #if. Also see Microsoft's C# and other .NET languages, >> that put all of the type info in the objects, so you can use the object >> as a compiled include file. -John] > > 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. With a new language then it's much easier to arrange matters so that it's faster and simpler to compile. It might not even have conditional directives, or any preprocessor at all; (C needs them because it is a cruder, older language; I used to have conditional code, but no longer and in any case it seemed an unsatisfactory approach). -- Bartc