Re: Parallelizing (WAS: Death by pointers.)

A followup to my followup, concerning why C++ would be (is) an
abominable intermediate language. I don't think my remarks were very
informative, though they do sum up my general impression about as
politely and concisely as is possible.


My experience. years ago, working with C as an intermediate language,
is that the major thing to watch out for is any feature of C more
complicated than a floating point number. Structures are ok for
internal data structures, but you have to be very careful if think
you can use one for (for instance) a representation of a data
structure from the source (non-C) language. This was confirmed,
somewhat, by the people at Xerox PARC who used C as an intermediate
language in a Cedar-to-C compiler, and had a relatively ok
experience. If you really do treat it just like a portable
assembler, you are much less likely to be disappointed.


What does this have to do with C++? Basically, there's very little
in C++ that wasn't already in C that constitutes "portable assembly
language". There's exception handling, but even there you must be
wary of the C++ semantics for EH not matching those of the source
language. (For instance, does the language you intend to implement
support asynchronously thrown exceptions? How do you plan to
implement that in C++?) It's the goofy semantic mismatches that get
you.


C is also better when you are debugging the code that you generate,
if only for the otherwise trivial reason that the names it generates
are not further mangled (since you mangled them once already in the
source-to-C transformation). Doubly-mangled names are not much fun.


This is made worse, of course, by the relatively immature state of
C++ compilers, compared to C compilers. Cfront generates really
funny-looking code, often full of what would be silly tests that
shouldn't be necessary in an intermediate-language application. The
other compiler I've looked at in great detail generally produced what
I can only call "less mature" code than the C compilers. It was ok
post-optimization, but the debuggable code was often a good deal
worse.


speaking for myself,


David Chase
--

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