[fpc-pascal] FPClassChart

Mattias Gaertner nc-gaertnma at netcologne.de
Fri Apr 23 10:42:31 CEST 2010

On Fri, 23 Apr 2010 09:58:25 +0200
Graeme Geldenhuys <graemeg.lists at gmail.com> wrote:

> Mattias Gaertner het geskryf:
> > 
> > No. The fcl-passrc is not optimized for speed (it uses TList and
> > creates a lot of strings) and I would estimate it supports only
> > half of the fpc languages features. 
> Excluding your comment on lacking fpc language features... Is the speed
> difference between fcl-passrc parser and CodeTools parser really noticeable
> from a developer (end-user) using a IDE point of view, or is the speed
> difference only noticeable in "speed test" environments.

Well, the codetools are (too) slow on some operations. So adding a
magnitude won't help. 

> As far as I know fpdoc uses fcl-passrc, and I can't say I have really
> noticed a speed issue when generating docs. This brings me to another
> point. If fpdoc uses fcl-passrc parser, then surely it [the parsel] should
> support "more that half the fpc language features" otherwise fpdoc wouldn't
> be able to document (parse) the RTL and FCL. Correct?? So maybe your
> "supports only half" comment is a slight exaggeration?  Just my personal
> observation, I don't know fcl-passrc code at all.

The FCL has nice code. It does not use all the FPC features (tons of
modifiers, special compiler directives, nested classes) and not all the
Delphi "bugs" like ommitting semicolons.
Try the fcl-passrc or fpdoc on the test units.

> > The idea is to help find errors early. It helps me a lot. Maybe not
> > that much for others.
> > But I plan to add some more skips/ignores.
> Like many other features, wouldn't it be worth improving the code that is
> included with FPC instead of always reinventing the wheel? Maybe
> incorporate the CodeTools speed & features into fcl-passrc so that
> eventually CodeTools and any other project wanting to parse Object Pascal
> source code, could use fcl-passrc parser?

The parser is only 10% of the codetools and has different goals. It
allows back tracking, that means it knows where a token came from.
This is needed for editing. It allows parsing only the compiler
directives. It has unit interdependencies. It has various caches
supporting reparsing of units without rebuilding everything. It is not optimized to parse sources once, but often.

It is good to have a simple parser in the fcl.


More information about the fpc-pascal mailing list