Re: C Compiler in C++ (Alex Colvin)
17 May 2002 00:21:50 -0400

          From comp.compilers

Related articles
[2 earlier articles]
Re: C Compiler in C++ (Diego Novillo) (2002-05-12)
Re: C Compiler in C++ (2002-05-12)
Re: C Compiler in C++ (2002-05-12)
Re: C Compiler in C++ (Rodney M. Bates) (2002-05-13)
Re: C Compiler in C++ (Lex Spoon) (2002-05-13)
Re: C Compiler in C++ (2002-05-17)
Re: C Compiler in C++ (2002-05-17)
Re: C Compiler in C++ (2002-05-17)
Re: C Compiler in C++ (2002-05-17)
Re: C Compiler in C++ (Joachim Durchholz) (2002-05-23)
Re: C Compiler in C++ (Lars Duening) (2002-06-07)
| List of all articles for this month |

From: (Alex Colvin)
Newsgroups: comp.compilers
Date: 17 May 2002 00:21:50 -0400
Organization: The World Public Access UNIX, Brookline, MA
References: 02-05-039 02-05-071
Keywords: C, OOP, design
Posted-Date: 17 May 2002 00:21:50 EDT

>The C declarators reverse this. They put an already-known type above
>the type constructor and the name of the to-be-declared type or
>variable below. Whether this is good or bad is bait for a major flame

>But this inverted syntax cannot be applied consistently, because a
>tree node, while having as many children as you like, can have only
>one parent. So when you need to construct a new type out of more than
>one already-known type or value, it won't work. The only type
>constructor in C that uses this syntax style consistently is the
>pointer declarator, which only needs one already-know construct,
>namely, the referent type of the being-declared pointer type.

I guess I use a grammar where the declaration has a base, which is a
base-type (int, float, ...) or another declaration, and a declarator
(array, pointer, call). This lets declarations reduce in the correct order
for one-pass name resolution. I represent type by a linear thread through
the declaration, which which does run up through the declarator and down
through the base.

For example,
int a = 0, *b = malloc(2*sizeof *b), c[2];

looks something like the following (with nodes numbered in brackets

/ \
[11] [14]
/ \ / \
DCLR \ DEF(c) \
[9] \ [12] EXPR(2)
/ \ \ [13]
/ * \
/ [8] EXPR(2*sizeof *b))
/ \ [10]
[6] [7]
/ \
/ EXPR(0)
DCLR [5]
/ \
[2] [3]

The reduction of [4] declares (a), [9] declares b before [9] uses it,
[15] declares (c).

Type threads run through the interesting nodes from DEF() up past DCLR,
terminating down the left side past BASE.

[3]->[1] for (a),
[7]->[8]->[1] for (*b),
[12]->[14]->[1] for (c[]).

This works. There may well be better ways.

mac the naf

Post a followup to this message

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