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