Path: csiph.com!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Hans-Peter Diettrich Newsgroups: comp.compilers Subject: Re: Best language for implementing compilers? Date: Sun, 10 Mar 2019 16:13:07 +0100 Organization: Compilers Central Lines: 19 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <19-03-011@comp.compilers> References: <19-02-002@comp.compilers> <19-02-004@comp.compilers> <19-02-006@comp.compilers> <19-03-009@comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="54374"; mail-complaints-to="abuse@iecc.com" Keywords: C, parse Posted-Date: 10 Mar 2019 21:08:11 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:2177 Am 10.03.2019 um 12:13 schrieb Christopher F Clark: > All that said, the output of any decent > C/C++ lexer and parser generator is often more than fast enough. That's > despite lexing and parsing often taking upto a third of the compilation time. > BTW, lexing (because it looks at every character) is the dominant factor in > that. If so, then lexing were the dominant factor for *all* parsers with a lexer, not only for C/C++. My experience and the existence of specific workarounds identify two C specific properties as most time consuming, the preprocessor and the lack of a multi-module (project) compilation. None of these is related to a *lexer in the strict sense* (tokenizer), because it all happens in between the tokenizer and parser. DoDi