Path: utzoo!attcan!uunet!lll-winken!brutus.cs.uiuc.edu!jarthur!mti!adrian From: adrian@mti.mti.com (Adrian McCarthy) Newsgroups: comp.lang.misc Subject: Re: Relationship between C and C++ Keywords: portability myth Message-ID: <970@mti.mti.com> Date: 22 Mar 90 18:55:53 GMT References: <8432@hubcap.clemson.edu> <6515@eos.UUCP> <2944@castle.ed.ac.uk> Reply-To: adrian@mti.UUCP (Adrian McCarthy) Organization: Micro Technology, Anaheim, CA Lines: 70 In article peter@ficc.uu.net (Peter da Silva) writes: >There are only two languages I know of in which you can take a moderately >complex program and run it, without modification, on a wide variety of >platforms. > >One is Fortran, with the Software Tools library. >The other is C. > >Which would you rather use? [edited] >For what other language can I get compatible compilers for: > > UNIX > IBM-PC > Amiga > Atari ST > Macintosh > RSX-11/M > VAX/VMS > RMX-86 > >The only other language system that came close was UCSD Pascal, and it's dead. > >-- Peter da Silva I usually try to stay out of these, and I'm not trying to upset anyone. There is no compatible C compiler for UNIX and VAX/VMS, and there can't be because there are too many fundamental differences between these operating systems. The most obvious example of this is linkage. VAX C had to introduce two keywords "globaldef" and "globalref" to supplement "extern" in order to make linkage work as C dictates. (I'm not sure how GNU C handles this, but I'd be interested in hearing about it.) Another obvious example is the different syntax for filenames, which affects not only how include files are designated, but also requires the programmer to #ifdef his code to build the right syntax for run-time data files. I'd also venture a guess that signals require some basic differences. Now if you want to talk about *actual code* that's out there that you can drop into either environment, the field narrows considerably. I have yet to see a C program written in VMS or UNIX environment that sticks strictly to the standard library *and* uses it correctly. Things like types.h, setitimer(), getopt(), fork(), and curses are *not* in the library. Although the standard library requires the presence of things like gmtime(), that doesn't mean a program can rely on them -- the standard allows gmtime() to return NULL if GMT time isn't available on the host system. system() calls obviously require a different syntax (assuming the same function is even available) and have system-dependent return values. And how many C programmers out there realize that external variables are not necessarily case-sensitive and that they are only guaranteed to be unique to six characters? In summary, C compilers can asymtotically [sp?] approach compatibility, but the amount of portable code out there will remain rather small. I'm not flaming C; I'm merely pointing out that strictly ANSI C-compliant code is no more or less portable than any other well standardized language such as FORTRAN or Pascal except that C has the advantage of its preprocessor which lets host-dependent operations to be enumerated with #ifdef. The reason so few people stick strictly to the standards (of any of the languages mentioned here) is because it almost always fails to have enough power to get the given job done without system-dependent extensions. Exercise for the reader: write a *portable* program in any language which takes a file name as its parameter and returns the modification or creation date and time of that file. Don't use any conditional compilation. Aid.