Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!mailrus!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!lavaca.uh.edu!uhnix1!sugar!ficc!peter From: peter@ficc.uu.net (Peter da Silva) Newsgroups: comp.lang.misc Subject: Re: Relationship between C and C++ Keywords: portability myth Message-ID: Date: 22 Mar 90 23:42:09 GMT References: <8432@hubcap.clemson.edu> <6515@eos.UUCP> <2944@castle.ed.ac.uk> <970@mti.mti.com> Reply-To: peter@ficc.uu.net (Peter da Silva) Organization: Xenix Support, FICC Lines: 56 > 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. I dont think that's the case. As far as I can tell, every place where the VAX compiler is substantially different from the UNIX compiler has been a gratuitous change. For example, the use of: #include stdio instead of: #include C does not require that there actually be a file called "stdio.h" anywhere on the system. It just requires that it be available in a standard place. Like a library. Then there's the ref/def problem: > 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. Again, there are other systems with ref/def semantics where C functions quite well without new magic words. In every case it is possible to determine whether a given use of the keyword extern should be interpreted as a PUBLIC or an EXTERNAL (globalref or globaldef). And it's acceptable for a C compiler to refuse to accept a program that depends on the traditional fortran/common semantics of globals. The fact that Eunice runs under VAX/VMS and provides a fairly conventional UNIX programming environment puts paid to any claim that VAX/VMS itself requires any of the gratuitous incompatibilities that DEC has peppered its compiler with. Again, other people deal with filename syntax differences. I work with three syntaxes myself right now: "/path/.../file", "dev:path/file", and ":DV:file". It just requires a little encapsulation. I have in the past attempted to get some interest in standardising this encapsulation, with little luck. In any case, most programs don't need to parse file names... they can treat them as magic cookies. > In summary, C compilers can asymtotically [sp?] approach compatibility, > but the amount of portable code out there will remain rather small. but at least in C you have a running chance at doing it. There are (except for a few cases like DEC's) no gratuitous incompatibilities between machines. And even for DEC portability is within reach. I myself ported a version of Make from MS-DOS to VAX/VMS, about 3 years ago, because I needed to. It was not overwhelmingly painful... despite DEC's hostile attitude towards C. > 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. Well, I can do it for any system where the C library is produced by a third party with some interest in maintaining compatibility. I'll just call stat(). -- _--_|\ `-_-' Peter da Silva. +1 713 274 5180. . / \ 'U` \_.--._/ v