Re: Building C/C++ compilers

"Robert J. Simpson" <robert@simpson190.fsnet.co.uk>
17 Dec 2004 00:33:24 -0500

          From comp.compilers

Related articles
Building C/C++ compilers sigurd@lerstad.com (Sigurd Lerstad) (2004-12-16)
Re: Building C/C++ compilers vidar@hokstad.name (Vidar Hokstad) (2004-12-17)
Re: Building C/C++ compilers robert@simpson190.fsnet.co.uk (Robert J. Simpson) (2004-12-17)
Re: Building C/C++ compilers camille@bluegrass.net (David Lindauer) (2004-12-17)
| List of all articles for this month |
From: "Robert J. Simpson" <robert@simpson190.fsnet.co.uk>
Newsgroups: comp.compilers
Date: 17 Dec 2004 00:33:24 -0500
Organization: Eurofeeds
References: 04-12-073
Keywords: C++, parse
Posted-Date: 17 Dec 2004 00:33:24 EST

"Sigurd Lerstad" <sigurd@lerstad.com> wrote


> I'm trying to make a C/C++ compiler.
>
[...]
>
> In the phase to produce Abstract Syntax Tree (AST) from the source. C/C++
> has a difficult case that has an amiguity
>
> g * h
>
> this can mean declare a variable pointer to g named h, or the variable g
> multiplied with h;
>
> In the above mentioned book, Appel first builds a syntax tree and then
> does
> semantic analysis, i.e. type checking etc.
> but it seems to me that because of the above ambiguity, ast building and
> semantic analysis must be performed at the same time ?


I would advise you to do symbol lookup before parsing. That way you will get
a TYPENAME token or an IDENTIFIER token.




> C++ makes it even more difficult, consider this example:
>
> class myclass
> {
> int method()
> {
> g* h;
> }
>
> typedef int g;
> }
>
> Now, g is declared later in the source, which complicates things even
> more.


Yes, you have to consider the function body to occur 'after' the
declarations. I don't know if it even possible to do this with
bison. You could parse it as 'g times h' and then manually convert
when you find g is a type. My preferred way of doing this is to use a
two pass approach. The first pass can be very crude e.g. just match
'{' and '}' or you can do a full parse and discard the result.


> Does anyone have any pointers to me overcoming these two issues,
> also on the light of using bison as the parser.


Personally I never use yacc or bison where the language is
defined. They are very useful when developing a language but it's such
a small proportion of the total work in writing a compiler and it
really restricts what you can do.


Rob.


Post a followup to this message

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