kanner@tymix.UUCP (Herb Kanner) (03/28/86)
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? 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? 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? 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? What other problems in building such a cross compiler might we expect? -- Herb Kanner McDonnell Douglas (TYMNET) ...!hplabs!oliveb!tymix!kanner
kanner@tymix.UUCP (Herb Kanner) (03/28/86)
An additional question suggested by a colleague: Are there any runtime routines used by C++ other than those included in the standard C library? -- Herb Kanner McDonnell Douglas (TYMNET) ...!hplabs!oliveb!tymix!kanner
bs@alice.UucP (Bjarne Stroustrup) (04/01/86)
> 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.
mwherman@watcgl.UUCP (Michael W. Herman) (04/06/86)
Has anyone had any significant luck using dbx with c++? Using the versions of c++ and dbx available here, dbx used to loose track of what source file it was in. Often it would have the correct source line number but it would think you were in a header file rather than the source file for the function you were in.