Re: implementing #include etc without pre-preprocessing

"Scott Stanchfield" <thetick@scruz.net>
18 Mar 1997 13:01:33 -0500

          From comp.compilers

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)
| List of all articles for this month |

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]
>


--


Post a followup to this message

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