Re: [RFC] type safe trees

[Stelios Xanthakis <sxanth at ceid dot upatras dot gr>]

On Fri, 25 Jun 2004, Joe Buck wrote:

> On Fri, Jun 25, 2004 at 11:45:44PM +0200, Gabriel Dos Reis wrote:
> > It is probably harder to first bootstrap a C++ compiler that
> > support full ISO C++; but the proposal wasn't to use full C++.
> > In fact, I maintain it is hardly harder to bootstrap the subset
> > of C++ that appeared in TC++PL1 than C90.
> 
> Other than exceptions, there shouldn't be any particular difficulty
> in first bootstrapping a new compiler that isn't already present in
> C.   So, a requirement that the compiler work with -fno-exceptions
> could be imposed.  Beyond that, it doesn't seem that anything else
> in the language causes any bootstrap difficulty, as everything else
> can be thought of as C code in disguise (remember cfront).
> 

Having written a C++-subset to C converter (which is in the public
domain and beats cfront big time), I can tell you that C++ should
not be taken as "the next generation language" in its entirety.
It's more like that things just ended up like this and nobody knew what
they were doing at the time.
Main thing about it is: local scope < class scope < global scope
automatically for member functions, including inheritance displacements.
Although the above can be done by hand in C, C++ saves the programmer
from a lot of "remembering" and that's very important.
vtbls are great for true OOP and polymorphism.

Everything else is irrelevant.
Templates'd better be avoided because next you'll be tempted
to use boost libs.
Exceptions with no run-time overhead would be great for the
parser but it can be done manually and they don't have to throw types!

If you want to go in that direction, I'd strongly suggest lwc
[http://students.ceid.upatras.gr/~sxanth/lwc]
although IMHO the compiler speed should not be an issue because
computers do get faster every day and it'd be better to invest the
effort implementing CIL or improving the intelligence of the optimizer.

Finally, a quick way to boost the speed of the compiler is to go the
lwc way: make lexical analysis a seperate pass which builds a big table
where all the tokens are ints. Then the syntactical parser can move
forward, backwards, jump, modify etc. 

Also use dbs trees.


stelios

// please stop mentioning cfront