Parser

"Aaron Becher" <aaron.becher@eds.com>
12 Sep 2002 00:34:07 -0400

          From comp.compilers

Related articles
Parser aaron.becher@eds.com (Aaron Becher) (2002-09-12)
Re: Parser lindig@eecs.harvard.edu (Christian Lindig) (2002-09-12)
Putting probes in source code (was: Parser) idbaxter@semdesigns.com (Ira Baxter) (2002-09-12)
Re: Parser knyblad@baan.com (Karsten Nyblad) (2002-09-12)
Re: Parser fjscipio@rochester.rr.com (Fred J. Scipione) (2002-09-14)
Re: Parser jakacki@hotmail.com (Grzegorz Jakacki) (2002-09-14)
Re: Parser vbdis@aol.com (VBDis) (2002-09-14)
[1 later articles]
| List of all articles for this month |

From: "Aaron Becher" <aaron.becher@eds.com>
Newsgroups: comp.compilers
Date: 12 Sep 2002 00:34:07 -0400
Organization: EDS PLM Solutions
Keywords: parse, question
Posted-Date: 12 Sep 2002 00:34:07 EDT

What would be the best approach? I have a VERY large pool of source
code that needs a certain line of code inserted at the beginning of
every function (a macro). A few years ago, I created from scratch a
tool that could parse our C and C++ source code and insert and/or
maintain this line of code at the beginning of every
function. However, it does run into problems now and then, especially
when our coding standard is not followed.


Well, we've just inherited a whole bunch of new code that does
not follow or coding standard, so I know my little parser tool I wrote
is going to fall to pieces. I was thinking a good idea might be to take
an open source compiler, which knows how to truly parse the code, and
try to start there. But I'm not covinced this is the best route. Does
anybody have any suggestions? Or know of an open-source compiler that
would be a good starting point? Also, I know OF lex and yacc, but don't
really know what they are for (or all of these other "lexical analyzer"
type tools). Sometimes I feel like they are what I really need and I
just don't know it...


Thanks for ANY help or links to information that could help me out,


Aaron Becher
[Using a regular parser in a rewrite tool is usually an exercise in
frustration, because the parser throws away info that you'd want to
keep in the rewritten source code. C is particularly unpleasant in
this regard because compilers generally start by expanding the
preprocessor stuff, then compile the expanded stuff, by which time
it's pretty much impossible to reconstruct the source. My experience
is that regular expression pattern matching combined with ad-hoc
heuristics give about as good result as any. -John]



Post a followup to this message

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