TITLE: History and C++ compatibility with C9X (Newsgroups: comp.std.c++, 4 Dec 98) ALLANW: AllanW@my-dejanews.com >>> Can anyone remember a case before C++, where some language FOO was >>> directly derived from (and not merely influenced by) some other >>> language BAR, to the point of remaining upwards-compatible with >>> most real (but not neccesarily all theoretical) BAR programs -- >>> and yet BAR also remained as a distinct, evolving language? >>> If so, what happened when BAR continued to evolve -- did FOO >>> accept most of the changes as well, or did the languages grow >>> in different directions? WADE: "Bill Wade" >> Ratfor ("Software Tools", Kernighan & Plauger, Addison-Wesley, 1976) >> might fit the bill. ... >> >> When f77 came around with better control structures, we saw and used >> enhanced versions of ratfor which generated "cleaner" fortran. >> >> Before f90 rolled around, the macro processor in our version of ratfor >> allowed us to declare and use UDT's (which are also in f90, I believe). >> Before we ever used an f90 compiler, we had converted all of our ratfor >> source to C++. [snip] >> Some would correctly argue that Ratfor was merely a preprocessing >> language. Of course for most of its life C++ has been merely a >> preprocessing language (cfront). STRUSTRUP: Bjarne Stroustrup Oldtimers here will know that I I object to statements like "for most of its life C++ has been merely a preprocessing language." I object politely, but firmly. Before C++, I designed and implemented a preprocessor language in the tradition of Ratfor (I worked in the research center where Ratfor originated). This language, C with Classes, convinced me that only a traditional compiler front end could cope with the syntax, the type checking, and the semantic transformations needed by C++. So I built such a traditional front end, named Cfront. Users of traditional preprocessors, such as Ratfor and my C with Classes preprocessor, invariably have problems with two different programs detecting and reporting errors (rather than one), with symbolic debugging, etc. My implementation of C++ avoided these problems by having Cfront do a complete syntax and semantics analysis of the source code and using C as an output language, "an assembler", only. By using C as an assembler, I achieved one of the most valuable aspects of a preprocessor - easy portability - without the problems of a preprocessor. (The standard C/C++ preprocessor, cpp, is yet another problem). See "The Design and Evolution of C++" for details. I think the C/C++ situation is unique in the history of formal standards. It is a bit as if the Fortran77 and Fortran90 committees had parted ways and simultaneously worked on standards - which inevitably would compete. The situation resembles the situation in the Lisp world where many reject the official standard and the Unix world where dialects continuously feud for primacy. In both cases, the lack of a single standard (fatally?) weakened the community leaving the field open for (inferior?) alternatives. I had hoped that C++ would one day become C, or C become C++, - and worked hard to ensure an unprecedented degree of compatibility between C and C++. However, so far this convergence has not happened. A significant fraction of the C community didn't/don't share my ideal of convergence - and with the new C standard coming up the next chance won't be for another 5 to 10 years.