Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!ut-emx!nowhere!sking
From: sking@nowhere.uucp (Steven King)
Newsgroups: comp.lang.c++
Subject: Re: How compatible are the various C++ implementations?
Message-ID: <1990Oct17.021132.4175@nowhere.uucp>
Date: 17 Oct 90 02:11:32 GMT
Organization: nowhere
Lines: 43

>In article <475@taumet.comme>> steve@taumet.com (Stephen Clamage> writes:
>sking@nowhere.uucp (Steven King> writes:
>
>>   It was for these same reasons (and cost as well> that I choose a translator
>>as opposed to a native code compiler. Instead of purchasing seperate C++ 
>>compilers for each target (even assuming they were availible> I have a single
>>C++ translator running on my host platform (386 unix> that can produce C source
>>for 8051, v40 (a 80186 sort of>, 68k, this here box, or anything else that has
>>a C compiler for it. I dont have to worry about compatibility at the C++ level
>>since the C output is the same for each target, one only needs to evaluate the
>>capabilities of the target C compiler.
>
>This seems attractive, but is not as reliable as you make it sound.  For
>non-trivial C++ programs, the C code produced by the translator will not
>necessarily work on arbitrary target machines.  For example, the
>translator knows the sizes of data types (especially ints and pointers),
>and generates references which depend on knowing those sizes.  If a
>target uses other sizes, the C code will be wrong.  If you use the AT&T
>cfront translator, you can purchase the source so that you can recompile
>it for use with different targets.  It is, however expensive.

	This could be a problem for others, however, both the implementations
of cfront that I use ( Guidelines & Intek ) provide a mechanism for specifying
a "size" file that informs the translator of the correct size and alignments
for the target. It has been my experiance that the translator, in general, is
quite nice about leaving the determination of size of items up to the target
C complier. An exception to this is in the call to constructors of member
objects; the offset for the member is calculated based upon what the translator
believes the sizes are. Packing of classes/structures by the target C compiler
also impacts this; I created some additional size files for this....

>In any event, you need still need source for the runtime support code used
>by the translator so that this code can be compiled for use with the
>various targets.  

	Again, both versions that I use supplied source for _main() and the
_patch_ mechanism of initialization of global objects. Source to the task and
complex math class library would be nice, but hardly indepensible; I would
find it quite pleasant to have source to the iostream library...

-- 
new && improved:			 			 sking@nowhere
old && reliable:			...!cs.utexas.edu!ut-emx!nowhere!sking