Related articles |
---|
implementing #include etc without pre-preprocessing sfrederi@asc.corp.mot.com (Sudhakar Frederick) (1997-03-16) |
Re: implementing #include etc without pre-preprocessing thetick@scruz.net (Scott Stanchfield) (1997-03-18) |
Re: implementing #include etc without pre-preprocessing bothner@cygnus.com (1997-03-21) |
Re: implementing #include etc without pre-preprocessing ftit07bv85@pop.anti.wanadoo.spam.fr (1997-03-21) |
Re: implementing #include etc without pre-preprocessing ok@cs.rmit.edu.au (1997-03-21) |
Re: implementing #include etc without pre-preprocessing sethml@ugcs.caltech.edu (1997-03-22) |
From: | "Scott Stanchfield" <thetick@scruz.net> |
Newsgroups: | comp.compilers |
Date: | 18 Mar 1997 13:01:33 -0500 |
Organization: | scruz-net |
References: | 97-03-090 |
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
--
---------
Scott Stanchfield, Santa Cruz CA
See my PCCTS Tutorial at
http://www.scruz.net/~thetick/pcctstut
Sudhakar Frederick <sfrederi@asc.corp.mot.com> 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
comp.compilers page.
Search the
comp.compilers archives again.