Re: [using gcc book] ch1 objective-c blurb

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Colin Douglas Howell <chowell2@pacbell.net> 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
  language," etc.

       -- 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.


-- Gaby