Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!deimos.cis.ksu.edu!rutgers!bellcore!faline!thumper!ulysses!andante!alice!ark
From: ark@alice.UUCP (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: C++ --> C
Message-ID: <9212@alice.UUCP>
Date: 18 Apr 89 13:02:22 GMT
References: <173@cs.columbia.edu> <7050005@hpcupt1.HP.COM> <9204@alice.UUCP> <5408@videovax.tv.Tek.com>
Organization: AT&T Bell Laboratories, Liberty Corner NJ
Lines: 53

In article <5408@videovax.tv.Tek.com>, bart@videovax.tv.Tek.com (Bart Massey) writes:

> One way of looking at it is that cfront is a compromise between two distinct
> design goals:  (1) produce "correct", efficient C code from C++ code, and
> (2) produce C code which is as much like the original C++ code as possible,
> and thus is still fairly "human-readable".  Most "true" compilers are only
> concerned with (1).  Note that (2) is much easier than (1), for translations
> to both C and assembly language.

Cfront is only concerned with (1).

> For example, people say that inline functions in G++ are "compiled in",
> whereas they don't tend to say this about inlines in cfront.  This is
> because G++ inserts code with the appropriate semantics inline, whereas
> cfront attempts to simply copy the appropriate code in without fully
> understanding its semantics, thus introducing significant restrictions in
> "inlineability".  My definition of "true" compilation would involve the
> process of semantic analysis followed by "from scratch" code generation.

I'm not sure what you're trying to say here.  Are you saying that
cfront inline expansion is often incorrect?  If so, you're wrong.
Are you saying that cfront handles inline functions by macro-expansion
on C++ source text?  If so, your're wrong there too.

Any C++ compiler that attempts inline expansion without `understanding
its semantics' will find that a recursive call of an inline function
will, um, throw it for a loop.

> One can imagine writing a back-end for GNU G++ which produced C-code (in
> fact some friends and I have partially completed such a beast).  I would
> call this hypothetical machine a "true" compiler, but cfront a "translator",
> though they both translate C++ to C.

Why?  Cfront does everything a GNU C++ that produces C would.  It does
the same kind of complete syntax and semantic analysis that any compiler
does, resulting in an internal data structure that it traverses to
produce C.  If it didn't do a full analysis, it would routinely
translate erroneous C++ programs into erroneous C programs --
but it doesn't.

There are only two ways in which cfront tries to make that C similar
to the input C++: it maintains a close correspondence between C++
external names and C external names (to facilitate linkage between
C and C++ programs) and it tries to translate each C++
expression-statement into a single C expression-statement
(mostly for reasons of efficiency and convenience).

Aside from that, I can assure you that the easiest way to understand
the C code generated by cfront is to translate it into assembly language
and read that.
-- 
				--Andrew Koenig
				  ark@europa.att.com