Related articles |
---|
[7 earlier articles] |
Re: Is C++ really used ? cdg@nullstone.com (Christopher Glaeser) (1997-05-04) |
Is C++ really used ? peter@bj-ig.de (Peter Brueckner) (1997-05-04) |
Re: Is C++ really used ? danwang@nordica.CS.Princeton.EDU (1997-05-07) |
Re: Is C++ really used ? kbreinho@bsquare.com (Keith L. Breinholt) (1997-05-08) |
Re: Is C++ really used ? geert@sun3.iaf.nl (1997-05-08) |
Re: Is C++ really used ? David.Monniaux@ens-lyon.fr (1997-05-08) |
Re: Is C++ really used ? chase@world.std.com (David Chase) (1997-05-08) |
Re: Is C++ really used ? clark@quarry.zk3.dec.com (1997-05-08) |
Re: Is C++ really used ? cliffc@risc.sps.mot.com (Cliff Click) (1997-05-08) |
Re: Is C++ really used ? nasser@apldbio.COM (Nasser Abbasi) (1997-05-08) |
Re: Is C++ really used ? shankar@chromatic.com (1997-05-08) |
Re: Is C++ really used ? bduncan@tiac.net (Bruce Duncan) (1997-05-08) |
Re: Is C++ really used ? cfc@world.std.com (1997-05-12) |
[2 later articles] |
From: | David Chase <chase@world.std.com> |
Newsgroups: | comp.compilers |
Date: | 8 May 1997 21:19:36 -0400 |
Organization: | Compilers Central |
References: | 97-04-156 97-04-167 97-05-048 |
Keywords: | Java, C++, practice |
> > With Java (I'm working on a compiler written in Java right now)
> > you've got all sorts of nice features that are lacking from C++ that
> > make it easier to get working programs written quickly, and it is
> > not so complex as C++.
Christopher Glaeser wrote:
> Please expand. Given that you are currently writing a compiler in
> Java, I'm interested in hearing more about what features make it
> suitable for writing a compiler.
1. garbage collection. Compilers can contain twisty little data
structures, it's great if you don't have to remember when to let them
go, or (worse) recycle them too early. Since people only care about
end-to-end compilation performance (there's no interaction) there's
few constraints on the garbage collector.
2. exceptions done right. No mention of any exceptions thrown means
throws-none, except for the program-failure exceptions (array bounds
checks, for example). This looks like the best compromise to me.
3. built-in checking of casts and array bounds. C++ tools to do this
are cumbersome and slow. I recently finished working on the fastest
one available (for C++, it's called C++Expert); it may run faster than
interpreted Java, but it does not approach the performance of compiled
Modula-3, and I expect similar results for compiled Java.
4. reduced confusion. There IS function overloading, but no default
parameters, only one default conversion (to string, in certain
contexts), and none of these implicitly-invoked copy constructors
and/or temporaries (with their vaguely-defined and
inconsistently-implemented lifetimes). "Multiple inheritance" has
been largely sanitized by removing the question of multiply inherited
data, and only allowing inheritance of interfaces. This removes some
function from the language, but removes a lot of confusion.
5. no templates, so no problems with template instantiation. We've
written our own tools to do this, and we're happy with them. (I've
had an exceptionally bad time with templates -- I crashed one vendor's
compiler, and provoked g++ into spitting out a single, full-page error
message, all with a piece of legal code. Some vendor's compilers just
choke on perfectly legal code. The set of vendors here is Sun, HP,
IBM, NCR, and MicroSoft). I expect, down the road, that something
more sensible that what we are doing will appear, and when it appears,
it will be more well-behaved than C++ templates (I have not looked at
the Pizza proposal carefully, I suppose I should. I think that
Barbara Liskov's group at MIT has a better proposal, but I'm not sure
which one is "winning".)
6. a proper definition, so increased portability. In C++, last job,
we pretty much gave up on vendor compilers and went to g++.
7. a decent library supplied with the language.
Note, too, that there's no graphics in our compiler, so we really
don't need to think about AWT, which (so I understand) is a good
thing.
David Chase
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.