Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!lupine!rfg
From: rfg@NCD.COM (Ron Guilmette)
Newsgroups: comp.lang.c++
Subject: Re: How compatible are the various C++ implementations?
Message-ID: <2391@lupine.NCD.COM>
Date: 3 Nov 90 04:36:56 GMT
References: <901012.051006.5031@nowhere.uucp> <475@taumet.com>
Organization: Network Computing Devices, Inc., Mt. View, CA
Lines: 59

In article <475@taumet.com> 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.

Additionally, when considering a translator as opposed to a debugger,
consider also the type of symbolic debugging support available.  Some
firms (most notably ParcPlace) have made some very large strides
towards providing symbolic debugging support in conjunction with a
translator, but it ain't necessarily cheap.

Anyway, if you are *seriously* concerned about portability of your code
between various platforms, there are a few things that I would recommend:

	First, try to learn what things that make C code non-portable.
	Then avoid such usage.  In particular, avoid things that the
	ANSI C standard says are implementation dependent.  I am often 
	amazed at the high level of ignorance which many professional
	C coders have about what the ANSI C standard says.

	Second, try to learn what things make C++ code non-portable.
	For example, don't write code which will break if the format
	of virtual function tables changes a little or a lot.

	Third, support the ANSI C++ standardization effort.

	Forth, beat all suppliers of (so called) C++ language processors
	about the head and neck over each and every deviation
	from E&S (unless of course that deviation has been approved by
	x3j16).  You will end up getting better C++ language products, and
	people may even thank you for it.

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

Ditto for `standard' libraries for compilers.

-- 

// Ron Guilmette  -  C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.