Re: C Compiler in C++

On 8 May 2002 00:15:31 -0400, Nemanja Stanarevic
  <stanarevic@hotmail.com> wrote:




>I organized the parse tree so that class PTN (Parse tree node) is a
>super-class for all node classes. Than, I derive nodes such as
>PTNBinaryOperation, PTNAssignment, PTNIf, PTNSequence (sequence of
>statements), etc. Please note that in this implementation a node can
>have 0..n children.


I've found this approach is somewhat problematical. When you parse an
expression, you have to return a pointer/reference to the base class.
The operand of a binary expression can be any expression, not just,
say, an assignment expression. This means you pretty much either wind
up downcasting (casting base to derived, possibly using tag fields in
a switch statement, defeating the whole OO paradigm), or putting
specialized virtual functions into the base class (working around
encapsulaion) for each tree walking pass. Either way, it can get
pretty ugly quickly if you're not careful.




>However, I have no idea how to go about representing C variable
>declarations in the parse tree. The problem is that C grammar itself


You shouldn't be doing a parse tree anyway. You need to build an
Abstract Syntax Tree. There's a subtle, but important difference
between the two. The later eliminates nodes for the syntactic sugar
of the language (i.e. semicolons, curly braces, etc.). You may have
meant AST, many people get sloppy about the terms, but I want to make
sure you're clear.




>is very loose on rules for variable declarations. For example: extern
>int const unsigned volatile static foo; is syntactically correct, but
>semantically doesn't make sense. Also, int const const const const
>usigned bar; is both syntactically and semantically correct, but
>should emit a warning about multiple const qualifiers.


Ignoring the parsing issue for a moment, you can look at these as a
set of attributes. Each attribute has an incompatable set of
attributes. In practice, it makes more sense to catch this kind of
thing with a semantic check rather than trying to get define it in the
grammar.




>It almost looks like that I have to have a parse tree node class for
>each production in C grammar related to declarations (such as:
>declaration, declaration_list, declaration_specifiers,
>init_declarator_list, etc.). Once this parse tree is generated, I
>would have to go trough that structure and derive declarations in
>terms of typing system that I have in place (class hierarchy to
>support basic types, pointers to types, structs, unions, arrays of
>types, etc.) and report errors/warnings. But this is so terribly ugly
>- there is way too many parse tree nodes that need to be defined, and
>it seems redundant since I already have type hierarchy in place.
>
>Does anyone know of a good way (or generally accepted way) of
>representing the parse tree for C declarations using a similar class
>hierarchy?


Generally, you build the typeinfo during the parse. You don't pass up
the parse tree, you pass up a node representing the type. As you
reduce each production, you modify the object's information.


HTH,
Morris

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