Re: Visual Parse++ ?

dirkv@netcom.com says...
>Does anybody know how good the drop in C++ grammar for Visual Parse++ is
>( does it support templates, rtti ?)


No templates, no exceptions, no rtti, no bool, no symbol table, no
preprocessor.


The grammar is based on Jim Roskind's C++ YACC grammar, which is public
domain. Sandstone has altered it to fit their parser language. I've looked
at Roskind's original YACC grammar, which is heavily annotated to describe
the problems (ambiguities) that he encountered in developing the grammar.
I'd strongly recommend getting his stuff before looking at the Visual Parse++
version, because the annotations give valuable clues as to the difficulty of
finishing the grammar. You can find it by searching on the web for "Roskind
and grammar" or something like that.


It looks like exceptions, RTTI, and bool would be pretty easy to add, since
they are fairly separate rules from the rest of the grammar.


Roskind claims that adding templates to the grammar poses significant
difficulties because it introduces new ambiguities to a grammar that has
already been heavily inline-expanded. But see for yourself.


More importantly, IMHO, the grammar for Visual Parse++ has no symbol table,
which is a non-trivial task. Some symbol table is necessary just to parse
the C++ code, so that types and identifiers can be disambiguated.


>What is the performance of this parser ? Which other commercial parsers
>have a good C++ grammar available. Currently I'm using the PCCTS C++
>grammar, but I'm having some performance problems ( due to my own additions
>to the original grammar, to make it work with OWL/MFC/STL). So ideally I
>would like to find a parser which has support for the latest C++ language
>specification. ( Delphi would be a plus as well.)


I'm also working with the PCCTS C++ grammar. I can't vouch for its
performance, but from my study I've gleaned that the symbol table and the
token stream involve a lot of new/delete. I think that looking into
overloading operators new/delete for the symbol table entries and token
stream would be an immediate improvement.


You might also check out G++, which is fairly speedy and comes with source,
if you can handle the "copyright" restrictions. But I know little about it's
internals.


john lilley
--

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