Newsgroups: comp.object
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!think.com!linus!linus!linus!mbunix!emery
From: emery@aries.mitre.org (David Emery)
Subject: Re: ada-c++ productivity
In-Reply-To: chip@tct.uucp's message of 27 Mar 91 18:15:09 GMT
Message-ID: <EMERY.91Mar28111404@aries.mitre.org>
Sender: news@linus.mitre.org (News Service)
Nntp-Posting-Host: aries.mitre.org
Organization: The Mitre Corp., Bedford, MA.
References: <23084@as0c.sei.cmu.edu> <27ECFFBB.1F19@tct.uucp>
	<jls.669956572@rutabaga> <27F0E12E.5B35@tct.uucp>
Date: 28 Mar 91 11:14:04

There is a wide body of experience (and at least one book) on porting
C code.  Here are some observations:
	First:  How do you *know* if a compiler implements full ANSI
C?  We have some experience here moving ANSI code across compilers and
coming up with some unpleasent surprises, such as "Feature not
implemented" or "syntax error".    
	The same thing is even more true with C++.  The language
standardization effort is just now starting.
	Second:  How do you know if the entire library is implemented
correctly?  For instance, Microsoft C has signal handling routines in
its MS-DOS compiler, but it only handles Control-C.  There's no way to
get correct fork semantics on (single-tasking) MS-DOS.  
	Finally:  I've seen lots of C code that assumes int and *char
are interchangable.  Despite every book's advise to the contrary, it's
easy to write non-portable C code.  The problem with C is that it's
awfully hard to find these places when you're in the middle of a port.

C does have a lot more "default standard" library interfaces, and a
growing set of standard interfaces (e.g. most of the POSIX work).  Ada
is just starting into the "standard interfaces" business.   

However, the biggest advantage of Ada for portability is compiler
validation, that guarantees the compiler implements Ada semantics
correctly.  If C really wants portability, it needs a similar
validation suite.

			dave emery
			emery@aries.mitre.org



