Re: Looking for a fast C++ parser

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

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