Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site alice.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!alice!bs From: bs@alice.UucP (Bjarne Stroustrup) Newsgroups: net.lang.c++ Subject: Query to Bjarne (answer) Message-ID: <5227@alice.uUCp> Date: Mon, 31-Mar-86 21:33:23 EST Article-I.D.: alice.5227 Posted: Mon Mar 31 21:33:23 1986 Date-Received: Wed, 2-Apr-86 02:47:11 EST Organization: Bell Labs, Murray Hill Lines: 73 > From: kanner@tymix.UUCP (Herb Kanner) > Newsgroups: net.lang.c++ > Subject: Query to Bjarne > Organization: Tymnet Inc., Cupertino CA > > Here are a few questions, probably addressed to Bjarne Stroustrup, with > respect to the released version of the C++ compiler. > 1) Is the assumption that the compiler is released in the form of C source > a correct one? The released version of the C++ translator (commonly known as cfront) comes in C++ source form together with a C version of of cfront (generated by itself) for a VAX or a 3B. > 2) It is described as a front end, and in one of your news items you refer > to inspection of its C output. You also specifically call it "a front-end > that translates C++ into C." Later in the same sentence, you say that > cfront does all syntax and type checking and that the underlying C compiler > is used as a code generator only. Superficially, this sounds like a > contradiction. Is it that some options are set so that unnecessary > checking steps on the part of the C compiler are skipped because its input > is guaranteed to be clean? No, the C compiler goes through a ``completely unnecessary'' syntax and type checking step. I wish I could turn that off and go directly to the code generation part of cc. However, that would take away the portability that was the reason for generating C in the first place. You gain portability and lose cpu time when you must generate code. What you can reasonably hope for is that you re-gain that cpu time by using a better language and because the two pass approach (cfront + cc) yields error messages about 3 times faster than a one pass approach (such as ``plain'' cc). > 3) How do you do debugging with the current product? Is it to set dbx or > sdb flags on the C compiler, capture a copy of the intermediate C, and work > with that? That is ``approach number one''. It is not ideal, but it has been done. A better approach involves a debugger that can relate the object code to the C++ source. This has been done, but I don't know of any commercially available debuggers that does that. > 4) We are planning to use C++ to cross compile for a stand-alone (non-UNIX) > environment. What runtime functions must we implement in order to support > code generated by cfront? malloc() and free(). The C++ library contains a few more functions _main(), _ctors(), _dtors(), operator new(), and operator delete(), but they are trivial portable, and supplied in C++ source form. You will also have to provide an I/O library (printf and/or stream I/O). > What other problems in building such a cross compiler might we expect? Cfront needs to know the sizes and alignments used by the C compiler on the target machine. Typically, you get them wrong first time. Have a look at the description of how to port release 1.0 of C++ to a variety of machines posted to net.lang.c++ by Jonathan P. Leech at California Institute of Technology. It mentions most snags and their fixes. > Herb Kanner, McDonnell Douglas (TYMNET), ...!hplabs!oliveb!tymix!kanner > > An additional question suggested by a colleague: > > Are there any runtime routines used by C++ other than those included > in the standard C library? None that are essential for running programs, but C++ does come with a ``stream I/O library'' as described in the C++ book. There is also a library of functions and operators for complex arithmetic. Some rudementary facilities for creating generic types, and a library for writing event driven simulations a la Simula67. This ``task libray'' contains machine dependent code and a few lines of assembler so it will only run on a VAX.