Previous | Table of Contents | Next |
Please note that the C compiler is used as a code generator only. Any error message from the C compiler reflects an error in the C compiler or in Cfront, but not in the C++ source text. Every syntactic and semantic error is in principle caught by Cfront, the C++ compiler front-end. I stress this because there has been a long history of confusion about what Cfront is. It has been called a preprocessor because it generates C, and for people in the C community (and elsewhere), that has been taken as proof that Cfront was a rather simple programsomething like a macro preprocessor. People have thus deduced (wrongly) that a line-for-line translation from C++ to C is possible, that symbolic debugging at the C++ level is impossible when Cfront is used, that code generated by Cfront must be inferior to code generated by real compilers, that C++ wasnt a real language, and so on. Naturally, I have found such unfounded claims most annoyingespecially when they were leveled as criticisms of the C++ language. Several C++ compilers used Cfront together with local code generators without going through a C front end. To the user, the only obvious difference is faster compile times.
Cfront was only a compiler front end and could never be used for real programming by itself. It needed a driver to run the source file through the C preprocessor, Cpp, and then run the output of Cpp through Cfront and the output from Cfront through a C compiler:
In addition, the driver must ensure that dynamic (runtime) initialization is done. In Cfront 3.0, the driver becomes yet more elaborate as automatic template instantiation (section 6.6.3) is implemented (McClusky, 1992).
As mentioned, I decided to live within the constraints of traditional linkers. However, there was one constraint that I felt was too difficult to live with, yet so silly that I had a chance of fighting it if I had sufficient patience: Most traditional linkers had a very low limit on the number of characters that can be used in external names. A limit of 8 characters was common, and 6 characters and one case only are guaranteed to work as external names in Classical C; ANSI/ISO C accepts that limit also. Given that the name of a member function includes the name of its class and that the type of an overloaded function has to be reflected in the linkage process somehow or other, I had little choice. Consequently, I started (in 1982) lobbying for longer names in linkers. I dont know if my efforts actually had any effect, but these days, most linkers do give me the much larger number of characters I need. Cfront uses encodings to implement type-safe linkage in a way that makes a limit of 32 characters too low for comfort and even 256 is a bit tight at times (see section 6.3.3.3). In the interim, systems of hash coding of long identifiers have been used with archaic linkers, but that was never completely satisfactory.
Versions of C++ were often named by Cfront release numbers. Release 1.0 was the language as defined in The C++ Programming Language (Stroustrup, 1986a).
Releases 1.1 (June 1986) and 1.2 (February 1987) were primarily bug fix releases but also added pointers to members and protected members (section 6.4.1). Release 2.0 was a major cleanup that also introduced multiple inheritance (section 6.4.2) in June 1989. Release 2.1 (April 1990) was primarily a bug fix release that brought Cfront into line (almost) with the definition in The Annotated C++ Reference Manual (ARM) (Ellis & Stroustrup, 1990; see section 6.6.1). Release 3.0 (September 1991) added templates (section 6.6.3) as specified in the ARM. Release 4.0 from HP added exception handling (section 6.6.4) as specified in the ARM.
I wrote the first versions of Cfront (1.0, 1.1, 1.2) and maintained them; Steve Dewhurst worked on it with me for a few months before Release 1.0 in 1985. Laura Eaves did much of the work on the Cfront parser for Releases 1.0, 1.1, 2.1, and 3.0. I also did the lions share of the programming for Releases 1.2 and 2.0, but starting with Release 1.2, Stan Lippman also spent most of his time on Cfront. George Logothetis, Judy Ward, Nancy Wilkinson, and Stan Lippman did most of the work for Releases 2.1 and 3.0. The work on 2.0 was coordinated by Barbara Moo, and Andrew Koenig organized Cfront testing. Barbara also coordinated Releases 1.2, 2.1, and 3.0. Sam Haradhvala from Object Design Inc. did an initial implementation of templates in 1989 that Stan Lippman extended and completed for Release 3.0 in 1991. The initial implementation of exception handling in Cfront was done by Hewlett-Packard in 1992. In addition to these people who have produced code that has found its way into the main version of Cfront, many people have built local C++ compilers from it. Apple, Centerline (formerly Saber), ParcPlace, Sun, HP, and others shipped products that contained locally modified versions of Cfront.
Previous | Table of Contents | Next |