Path: utzoo!attcan!uunet!world!decwrl!apple!portal!cup.portal.com!ts
From: ts@cup.portal.com (Tim W Smith)
Newsgroups: comp.lang.c++
Subject: How compatible are the various C++ implementations?
Message-ID: <34661@cup.portal.com>
Date: 9 Oct 90 00:43:31 GMT
Organization: The Portal System (TM)
Lines: 67

We are thinking of moving from C to C++ as our primary
development language at work.  Before doing this, we
need to make sure that we can get a set of compilers
across various platforms that are compatible.

Most of our work is with standalone systems.  Right now,
we tend to use Turbo C or Microsoft C to write our stuff
if the target system has an 8086 family CPU, and Think C
if the target has a 68000 family CPU.  We take the output
of the compiler, wrap it in standalone "glue", and stick
it in the standalone system.

How well would this work with C++?  For example, suppose we
tried to use Turbo C++ and Apple MPW C++.  Since C++ is
relatively new, there are bugs in various implementations.
Are we going to spend a lot of time working around various
compiler bugs?  (Nothing is as annoying as a compiler bug
when working on embedded code.  Debugging facilities are
often quite primitive, so you can't just step through with
a source level debugger and see that the compiler has
screwed up (I recently worked on a project where my only
debugging aid was an LED that I could turn on or off.  Oh
well, it provided good practice for reading Morse code :-) ) )

We don't care about various add-on class libraries provided
by the compiler vendor.  We plan to implement our own that
are geared toward the stuff we write, so we only care about
the basic compiler.

In summary, 1) do the various C++ compilers out there now
really conform to the C++ standard?  2) Are they mature enough
that we won't be hit by obscure compiler bugs?  3) Are there
any compilers we need to avoid because they "know" that they
are on a particular system?  For example, a compiler that is
going to implement "new" by outputting a DOS INT instruction
to allocate memory would not be nice.  We need some way to
hook into this sort of thing so that we can provide it on
the standalong system.

I'm somewhat pessimistic at the moment since my very first attempt
to write a somewhat real C++ program found a big bug in Turbo C++.
If you overlead the comma operator, the compiler evaluates expressions
involving the overloaded operator wrong.  For example, if you have
a type T, and T,T yeilds a type T, then the expression

	T1,T2,T3,T4

where Ti is of type T is evauluated as

	(T1,T2),(T3,T4)

where the second comma is treated like the ordinary C comma
operator.

I would really hate to write some big standalong system for a 68000
using MPW C++, make heavy use of overloading the comma operator, then
port to an 80386 with Turbo C++ and find that I have to rewrite
everything to avoid overloading the comma operator.  This is the
kind of thing I want to avoid.

					Tim Smith

ps: the exact details in the above example may be wrong, as I am
doing it from memory.  The basic idea is right, however.  Expressions
with multiple comma operators failed with the failure being a comma
evaluated like a regular C comma rather than calling the overloading
function.  Changing the comma to << got rid of the problem.