Related articles |
---|
what parser generator? Drum.Sefex@btinternet.com (Paul Drummond) (2000-12-18) |
Re: what parser generator? broeker@physik.rwth-aachen.de (Hans-Bernhard Broeker) (2000-12-18) |
Re: what parser generator? idbaxter@semdesigns.com (Ira D. Baxter) (2000-12-19) |
Re: what parser generator? mike@dimmick.demon.co.uk (Mike Dimmick) (2000-12-19) |
Re: what parser generator? Drum.Sefex@btinternet.com (Paul Drummond) (2000-12-20) |
Re: what parser generator? idbaxter@semdesigns.com (Ira D. Baxter) (2000-12-21) |
Re: what parser generator? ralph@inputplus.demon.co.uk (2001-01-09) |
From: | Paul Drummond <Drum.Sefex@btinternet.com> |
Newsgroups: | comp.compilers |
Date: | 20 Dec 2000 17:28:14 -0500 |
Organization: | None |
References: | 00-12-079 00-12-083 00-12-086 |
Keywords: | C, parse |
Posted-Date: | 20 Dec 2000 17:28:13 EST |
Ira D. Baxter wrote:
> "Hans-Bernhard Broeker" <broeker@physik.rwth-aachen.de> wrote in message
>> Paul Drummond <Drum.Sefex@btinternet.com> wrote:
>> > I am writing a C++ DocTool for my 3yr uni project and I have been
>> > looking at different generators.
>
>> from my own experience with a C-analysing program, I can say that it's
>> probably your best bet to explicitly reflect the preprocessing phase
>> of C-like languages in your analyser. I.e. first preprocess to isolate
>> the comments from the rest of the text (keeping pointers into the
>> preprocessed text as links between them), and then lex/parse the
>> remaining text to understand the structure.
>
> And this of course means you have to write a comment-retaining
> preprocessor. (After all, your conventional preprocessor chucks the
> comments). Yuk! We think it is better to parse the unpreprocessed
> text directly.
I have tried parsing unpreprocessed text and it is practically
impossible, if you want your product to work on any piece of C++ code,
then there are loads of things that can cause problems! I am a linux
user these days but before that I used Windows MFC and I tested my
(crap) parser on the MFC code. Guess where it crapped out! There is
code like this:
do
{
#if MACRO1
}
while(blah);
#else
}
while(blah, blah);
How can you keep track of braces in a situation like this? Only
solution in my oppinion is to preprocess.
<<snip>>
>> You do have to, at least partly. It's the only reliable way of
>> finding the _end_ of a function. You have to at least count
>> braces. Not even to mention the occacional #ifdef section...
>
> The really bad part is that people write stuff like:
> #define BEGIN {
> So now you can't count matching braces without looking inside the macros.
> When you get conditional macro defintions, life gets really hard.
> This is what pushes you towards doing preprocessing; its a way
> of ducking macro-body analysis. We are working on the latter.
Please explain how far you have come to parsing without preprocessing.
Also, surely there is a ready-made preprocessor out there that gives
the user the option of leaving comments in????
[What you do about the preprocessor depends heavily on what your overall
goals are. You can certainly preprocess and parse the output, but if
you want to make a symbol cross-ref, that'll lose anything in #if that's
not included as well as all of the preprocessor symbols. I'd do pattern
matching and fake it. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.