Re: Building C/C++ compilers

David Lindauer <>
17 Dec 2004 00:42:50 -0500

          From comp.compilers

Related articles
Building C/C++ compilers (Sigurd Lerstad) (2004-12-16)
Re: Building C/C++ compilers (Vidar Hokstad) (2004-12-17)
Re: Building C/C++ compilers (Robert J. Simpson) (2004-12-17)
Re: Building C/C++ compilers (David Lindauer) (2004-12-17)
Execution Profiling? (Vidya Praveen) (2004-12-19)
| List of all articles for this month |

From: David Lindauer <>
Newsgroups: comp.compilers
Date: 17 Dec 2004 00:42:50 -0500
Organization: Flash NewsGroups
References: 04-12-073
Keywords: C++, parse
Posted-Date: 17 Dec 2004 00:42:50 EST

Sigurd Lerstad wrote:


> In the phase to produce Abstract Syntax Tree (AST) from the source. C/C++
> has a difficult case that has an amiguity
> g * h

One way of handling it is to keep track of symbol types; then you can
tell from whether g is a type identifier or a regular variable what
the deal is with this. That is different from type checking all the
identifiers found in say an expression or argument list. Another way
is to introduce an 'ambiguous' version of the '*' operator which will
flag the fact that a resolution is required when you type-check the

> C++ makes it even more difficult, consider this example:
> class myclass
> {
> int method()
> {
> g* h;
> }
> typedef int g;
> }

it gets even worse. Consider this:

class myclass {
        myclass method(myclass var)
                var.a = this->a ;
                return var ;
        int a,b,c ;
} ;

Now neither the size of myclass nor its members are known at the time
the method is encountered, so there is no way to completely specify
what is going on at that time. You can either create a very 'loose'
syntax tree and check it for validity later, or you can just defer
even trying to compile the method until the class declaration is


Post a followup to this message

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