esink@turia.dit.upm.es (Eric W. Sink) (05/23/91)
I've been thinking about augmenting a C compiler with some object oriented
features. Several months ago, I posting a question to the net, asking
how difficult it would be to modify a C compiler into a C++ compiler.
I'm fairly familiar with both languages, but have only a little understanding
of how C++ is traditionally implemented. Steve Clamage responded to my
question by email, I assume he doesn't mind my paraphrasing his response (I
lost the original note from Steve) :
Hard. Really hard. Most people don't realize just how difficult
is to parse C++. Any quantitative estimate of the effort would
no doubt be ruinously low. All known attempts at making a C++ compiler
out of a C compiler have failed.
[Steve, feel free to post and correct my paraphrase if necessary, but
I think I got the gist of it]
Well, I dropped the idea for quite a while, and have just picked it
back up again. In light of Steve's prophesy, I have lowered my aim
a bit.
Q: Given a working ANSI compliant C compiler, suppose that you want
to modify it to compile an object oriented superset of C. This
language must be a subset of C++. Handling all of C++ is deemed
to be not worth the effort for your project. What features of C++
would you implement ? Is there a subset of C++ which can be
implemented with reasonable effort, which would be useful ?
I am speculating that features like operator overloading, exceptions,
templates, multiple inheritance are out of the question. The features
I would *like* to try to implement are :
member functions, virtual and otherwise
inheritance
anything else that would not be too hard
(how about simply the ability to intermix declarations
with statements within a block)
Feel free to change my list, that's the point of the question.
Any responses appreciated. Those who want to tell me that the
creation of non-standard object oriented C like languages is
a waste of time should keep in mind that I do not attend to
win the world over with my language, merely to learn from its
implementation and gain the ability to use it myself.
Thanks in advance,
Eric
Eric W. Sink | "If no one is criticizing |Opinions
Departamento de Telematica | your work, it is possible |mine -
Universidad Politecnica de Madrid| that you are not doing |all of
esink@turia.dit.upm.es | anything." -George Verwer |them.bright@nazgul.UUCP (Walter Bright) (05/26/91)
In article <1991May23.115050.5755@dit.upm.es> esink@turia.dit.upm.es (Eric W. Sink) writes:
/Several months ago, I posting a question to the net, asking
/how difficult it would be to modify a C compiler into a C++ compiler.
/ Hard. Really hard. Most people don't realize just how difficult
/ is to parse C++. Any quantitative estimate of the effort would
/ no doubt be ruinously low. All known attempts at making a C++ compiler
/ out of a C compiler have failed.
Not true. Zortech C++ grew out of Zortech C. In fact, the sources for the
two parsers are the same, with #ifdef's for the differences. It turns out
that the C++ stuff nearly doubles the size of the parser.
C++ is like an iceberg, the visible part looks nice and pretty. What goes
on under the surface is pretty hairy and dangerous, and have sunk more
than one attempt to implement it.
Myself, (and some others!), thought that implementing a C++ compiler was
just adding a few keywords, and about 3 months of twiddling. Ha!
If you want a time estimate, try 2 to 3 years given an existing ANSI C
compiler.steve@taumet.com (Stephen Clamage) (05/29/91)
bright@nazgul.UUCP (Walter Bright) writes: >Not true. Zortech C++ grew out of Zortech C. In fact, the sources for the >two parsers are the same, with #ifdef's for the differences. It turns out >that the C++ stuff nearly doubles the size of the parser. >Myself, (and some others!), thought that implementing a C++ compiler was >just adding a few keywords, and about 3 months of twiddling. Ha! >If you want a time estimate, try 2 to 3 years given an existing ANSI C >compiler. On the other hand, it took us about 18 months to do our C++ compiler front end and library entirely from scratch -- we modified an existing optimizer and code generator from a Pascal compiler. (This first compiler was AT&T release 1.2 compatible. We later spent a few months more to upgrade to AT&T 2.0 compatiblity.) This might mean that it is faster to start over than to modify an existing compiler. (You can salvage the scanner, preprocessor, and code generator. Discard the parser and symbol table.) I know of other development efforts having spent more than 18 months trying to modify an existing C compiler without releasing a product. Some of these efforts were abandoned, others are still in progress. -- Steve Clamage, TauMetric Corp, steve@taumet.com