Re: Using a C struct to represent a node in a parse tree ... how many fields in the struct?

On 04/08/2022 01:17 PM, Roger L Costello wrote:
> Hi Folks,
>
> The compiler book [1] that I am reading says this:
>
> The most obvious way to represent the information gained from lexical and
> syntax analysis is as a tree along the lines of the parse tree. In C this is
> suitably handled using a simple struct for each node:
>
> struct node
> {
> int nodetype ;
> struct node *field1 ;
> struct node *field2 ;
> struct node *field3 ;
> struct node *field4 ;
> struct node *field5 ;
> } ;
>
> But, but, but, ..what if a node requires more than 5 fields; how is that
> handled?
>
> /Roger
>
> [1] Introduction to Compiling Techniques, A First Course Using ANSI C, LEX and
> YACC by J. P. Bennett, page 47.
> [Use a bigger struct. You know what kind of nodes your parser creates, so define
> a struct that does what you want. Personally, I prefer to define a struct for
> each node type and a general node that is a union, or perhaps a union of
> pointers. -John]
>
doesn't happen.
e.g. if/else is always 1 or two nodes. if they're deeper nested
it ends up in subnodes. as long as you use flex/yacc you'll just have to look
what's the highest number of nonterminals in your ruleset. and that's the number
of fields in your struct, possibly plus an identifying enum and usually some
union for the terminal symbols(as they won't have subnodes)
if you're overly anal you can prolly dynamic allocate those pointers.


> struct node
> {
> int nodetype ;
> node *fields[0];
> } ;

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