This is the mail archive of the
mailing list for the GCC project.
Re: [using gcc book] ch1 objective-c blurb
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Colin Douglas Howell <chowell2 at pacbell dot net>
- Cc: Chris Devers <cdevers at pobox dot com>, GCC list <gcc at gcc dot gnu dot org>
- Date: 26 Aug 2003 04:23:33 +0200
- Subject: Re: [using gcc book] ch1 objective-c blurb
- Organization: Integrable Solutions
- References: <Pine.OSX.email@example.com><3F4ABD02.firstname.lastname@example.org>
Colin Douglas Howell <email@example.com> writes:
| Chris Devers wrote:
| > After splitting the text of _Using and Porting GCC_ into the _Using..._
| > and _Porting..._ books, the material remaining in _Using..._ is primarily
| > about C, C++, and Objective-C support. Chapter one, which is only a page
| > long, includes paragraphs about the first two language, but doesn't really
| > discuss the Objective-C aspect.
| > Based roughly on what is said about C++/G++, I've taken a stab at a
| > writeup of the ObjC side, but I'd like to be sure that what I'm saying
| > isn't wildly inaccurate.
| > For comparison, here's the existing G++ writeup:
| > G++ is a compiler, not merely a preprocessor. G++ builds
| > object code directly from your C++ program source. There
| > is no intermediate C version of the program. (By contrast,
| > for example, some other implementations use a program that
| > generates a C program from your C++ source.) Avoiding an
| > intermediate C representation of the program means that you
| > get better object code, and better debugging information. The
| > GNU debugger, GDB, works with this information in the object
| > code to give you comprehensive C++ source-level editing
| > capabilities (see section .C and C++. in Debugging with GDB).
| > Here's my ObjC paragraph:
| > Compilation of Objective-C programs is done with GCC itself,
| > rather than a front end like G++ or GNAT. As with G++
| > programs, the lack of a preprocessor and the direct build
| > of object code from your Objective-C program source provides
| > better object code and better debugging capabilities.
| > Does this accurately reflect things? Is there anything else that
| > should be
| > mentioned?
| My first thought about this is that while some discussion of Objective C
| may be called for, the paragraph you propose above is completely unnecessary.
I disagree. Especially given what you say below. My comments do not
concern Objective-C, since I know next to nothing about it.
| The manual mentions that G++ doesn't use a preprocessor because the first
| popular C++ compiler, AT&T's CFRONT, actually *was* a preprocessor which used
| the normal C compiler as the back end. The GNU project wanted to
| emphasize that G++ had a superior implementation.
There is a misconception that because the front end uses C as an
intermdiate language means the resulting object code is inferior.
But, the fact is that the (defunct) KCC used C as an intermediate
language, still used to produce good code, performance wise speaking.
Debugging is a different story; yet, not just because a compiler uses
C intermdiate code automatically means the object is inferior.
Some EDG front end based compilers out there just use C as an
intermediate language and they do produce good (or superior) object code.
As of what Cfront is:
The most unusual -- for its time -- aspect of Cfront was that it
generated C code. This has caused no end of confusion. Cfront
generated C because I needed extreme portability for an initial
implementation and I considered C the most portable assembler
around. I could have easily generated some internal back-end format
or assembler from Cfront, but that was not what my users needed. [...]
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. In this, C++ and its Cfront implementation
differed from preprocessor-based languages such as Ratfor
[Kernighan, 1976] and Objective-C [Cox, 1986].
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 taken as a proof that Cfront was rather a simple program --
something like a macro preprocessor. People have thus "deduced"
(wrongly) that a line-for-line translation from C++ to C is
possible, that symbolique 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++ wasn't a "real
-- B. Stroustrup in "Design and Evolution of C++"
[Kernighan, 1976] Brian Kernighan and P.J. Plauger: Software tools.
Addison-Wesley, Reading MA. 1976.
[Cox, 1986] Brac Cox: Object-Oriented Programming: An Evolutionary
Approach. Addison-Wesley, Reading MA. 1986.