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