Re: Looking for a fast C++ parser

"Peter \"Firefly\" Lund" <firefly@diku.dk>
13 Aug 2005 00:25:48 -0400

          From comp.compilers

Related articles
Designing a language for dataflow/parallelism peteg42@gmail.com (Peter Gammie) (2005-06-26)
Looking for a fast C++ parser nscc@c7.org (2005-08-07)
Re: Looking for a fast C++ parser snicol@apk.net (Scott Nicol) (2005-08-10)
Re: Looking for a fast C++ parser vidar.hokstad@gmail.com (Vidar Hokstad) (2005-08-10)
Re: Looking for a fast C++ parser firefly@diku.dk (Peter \Firefly\Lund) (2005-08-13)
Re: Looking for a fast C++ parser snicol@apk.net (Scott Nicol) (2005-08-16)
Re: Looking for a fast C++ parser Martin.Ward@durham.ac.uk (Martin Ward) (2005-08-16)
Re: Looking for a fast C++ parser firefly@diku.dk (Peter \Firefly\Lund) (2005-08-16)
Re: Looking for a fast C++ parser firefly@diku.dk (Peter \Firefly\Lund) (2005-08-16)
Re: Looking for a fast C++ parser snicol@apk.net (Scott Nicol) (2005-08-16)
Re: Looking for a fast C++ parser firefly@diku.dk (Peter \Firefly\Lund) (2005-08-16)
| List of all articles for this month |

From: "Peter \"Firefly\" Lund" <firefly@diku.dk>
Newsgroups: comp.compilers
Date: 13 Aug 2005 00:25:48 -0400
Organization: Department of Computer Science, University of Copenhagen
References: 05-06-133 05-08-030 05-08-035
Keywords: C++, parse

On Wed, 10 Aug 2005, Scott Nicol wrote:


> A full parser for text highlighting is overkill, and it creates a
> problem. You have to expect the code being edited will have syntax
> errors, and it would be nice if the editor could handle these errors
> gracefully.


Yep.


A simple lexer-like thingie works *very* well, in my experience.
You can easily make it fast enough that it'll never be the bottleneck,
even on a 4.77 MHz machine :)


The hard stuff: handling block comments, deciding on whether to display
conditional compilation blocks differently, and handling line
continuations.


The easy stuff: everything else. Note that only block comments, line
continuations and possibly #if...#else...#endif requires knowledge from
before the start of the current line you are trying to colour.


If you handle the display update yourself, you don't have to store any
information about the colouring on each line, except for a start state for
each line. Each line is then handled as a (possibly handcoded) state
machine that generates the colouring on the fly. You don't even have to
calculate the start states for the whole fly at file load-time - you can
do it lazily. Some edits will of course change huge parts of the file
after the edit - but again, a lazy calculation of the start states will
make the editor snappy even on VERY old machines.


The current fashion in syntax coloring seems to be to use a generic editor
that attaches font and colour attributes to the text, combined with a
general regexp engine + a file of regexps per language that is used to
generate the colour attributes after loading the file into the editor
widget. This is both slower and more memory-hungry than it really needs to
be.


-Peter


Post a followup to this message

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