|implementing #include etc without pre-preprocessing email@example.com (Sudhakar Frederick) (1997-03-16)|
|Re: implementing #include etc without pre-preprocessing firstname.lastname@example.org (Scott Stanchfield) (1997-03-18)|
|Re: implementing #include etc without pre-preprocessing email@example.com (1997-03-21)|
|Re: implementing #include etc without pre-preprocessing firstname.lastname@example.org (1997-03-21)|
|Re: implementing #include etc without pre-preprocessing email@example.com (1997-03-21)|
|Re: implementing #include etc without pre-preprocessing firstname.lastname@example.org (1997-03-22)|
|From:||"Scott Stanchfield" <email@example.com>|
|Date:||18 Mar 1997 13:01:33 -0500|
|Keywords:||lex, parse, C|
As our moderator says, it can be done. The trick is to have a scanner that
performs extra processing on #if et al and only passes tokens to the parser
that are in the source text that pass the tests.
John mentions a parser for the expressions -- you really need a separate,
nested parser invocation called from the scanner for this. Otherwise your
grammar would need to have rules for #if everywhere...
One (easy) way to do this is with a recursive-descent parser, such as one
generated by PCCTS. Suppose your grammar had a start rule called
translationUnit and had a high-level expression rule called expression.
You create an extra start rule called startExpression that just matches
expression followed by EOF.
You would start your main parse by calling translationUnit, using a parser
that grabs tokens from a scanner that reads a text file.
When the scanner sees #if, it gobbles the rest of the line, and invokes
startExpression on it, using a scanner that reads the stored string instead
of a file. (Use a different instance of the same scanner, but make it read
from a string instead of a file.)
So you get the first scanner invoking the second scanner to parse the
expression, then set a flag based on the value of the expression, and have
that flag determine whether tokens are returned to the parser or sent to
the bit bucket.
Scott Stanchfield, Santa Cruz CA
See my PCCTS Tutorial at
Sudhakar Frederick <firstname.lastname@example.org> wrote
> Is it practical to implement "conditional compilation" C-style
> constructs similar to #include, #define #ifdef etc. as part of the
> parsing rather than through a pre-processor. I'm using Bison and Flex.
> [Look at the flex manpage, wherein is found great wisdom on creating,
> deleting, and switching among input buffers. Yes, you can do this
> although the expressions in #if require a complete expression parser. -John]
Return to the
Search the comp.compilers archives again.