[antlr-interest] Re: C++ grammar

[iank at bearcave.com]

> David Wigg's ANTLR wish list
>
> 1. A standard way of being able to pass Comments and Compiler
> Directives etc. through ANTLR (without having to find a way of
> fudging it yourself)
> 
> 2. A standard way of passing column number with text and/or token
> (ditto)

  I think that David has made a good point here.  It is not that this
  cannot be done in ANTLR as it exists.  And most people who write
  serious ANTLR parsers with nice error messages (which is one reason
  one uses ANTLR) do this.  Since many of us add these features, it
  might make sense to make these into builtin features.

  Since I'm throwing my few pennies into the ring, I'll throw
  out some thoughts on the C++ code generator.

  I have caught a disease called digital signal processing during the
  last year.  Wavelets have consumed my fevered brain, distracting me
  from all work on compilers.  I am only now starting to hope that
  recovery is on the way.  So I have not worked with the new code
  base.  However, when I last saw it, the code base (e.g., the ANTLR
  scanner) made heavy use of the C++ STL.

  I recently wrote a scanner/parser for an XML subset (OK, I guess I
  still do some lanuage processor related work) using STL.  It is much
  slower than I would have expected.  There are a variety of reasons
  for this, but the STL streams, at least on Solaris, seem to be
  slow.

  I have not actually benchmarked my Java parser, so I don't know how
  fast it is.  So I don't know if the overhead of STL is an issue.
  Also, in the past I've disregarded this issue, since I thought that
  the overhead of building the symbol table, doing semantic analysis
  and building the control flow/data flow graph would consume at least
  as much time as the parser, so the parser would not be the
  bottleneck.

  However, I keep thinking about Microsoft's C++ compiler compared to
  the Sun or GNU C++ compiler.  Microsoft's compiler is much faster
  (bless their little dark hearts).  From what I understand this may,
  in part, be attributable to the front end, which got a major rewrite
  somewhere around release 5.

  So has anyone looked at parser performance?  Is it worth the effort
  to think about removing STL from ANTLR?

  Ian Kaplan
  iank at bearcave.com
  www.bearcave.com


 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/