From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 10261c,90121986704b5776 X-Google-Attributes: gid10261c,public X-Google-Thread: 10c950,90121986704b5776 X-Google-Attributes: gid10c950,public X-Google-Thread: 109fba,4873305131bf4d94 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,4873305131bf4d94 X-Google-Attributes: gid1014db,public X-Google-Thread: fdb77,4873305131bf4d94 X-Google-Attributes: gidfdb77,public X-Google-Thread: 103376,4873305131bf4d94 X-Google-Attributes: gid103376,public From: Alan E & Carmel J Brain Subject: Re: Portability: C, C++, Ada Date: 1997/11/01 Message-ID: <345BA52D.56F1@dynamite.com.au>#1/1 X-Deja-AN: 287132587 References: <34557f2b.1934172@news.mindspring.com> <3456e71b.3833189@news.mindspring.com> <3459AC95.1D75@dynamite.com.au> <63aodd$t55$1@helios.crest.nt.com> Reply-To: aebrain@dynamite.com.au Organization: @home Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.lang.java.advocacy,comp.lang.pascal.ansi-iso,comp.lang.pascal.misc Date: 1997-11-01T00:00:00+00:00 List-Id: Kaz Kylheku wrote: > No. C is perceived as being portable. Those who perceive C++ as portable > are naive or mistaken. > C++ is not C however. What are your experiences with porting ANSI/ISO C code > from one ISO compiler to another? Fairly awful. You see, often there are compiler directives buried in there that assume a pre-processor of a particular variety. Usually named after a ruminant herbivore. I agree that my experience is probably unusual, and that the ISO standardisation of C has to make it vastly more portable than otherwise. > Even though it's easy to introduce machine dependencies into C or C++ code, I > would expect that most of your C++ headaches would be related to a lack of > standardization, or the different pace of adaptation of the draft features by > various vendors. (That alone is, to me, reason enough to avoid C++ if I can). Concur. > C porting headaches usually stem from legacy ``classic'' C code, in which the > chief difficulty is bugs uncovered when one adds function prototypes. Then > there are dependencies of implementation characteristics: byte order, size of > various types, and so forth. Completely agree. Regardless of the reason though, C porting headaches exist, as a general rule, do they not? > Mind you, it's also possible to write Ada programs with similar dependencies. Agree again. It's just difficult, and usual, is it not? > Then there are uses of non-portable functions that are not in the standard > library. E.g. it's impossible to port an XWindow application to Microsoft > Windows without rewriting portions of it, but it's not really the fault of the > underlying language. Concur yet again. At least in part. What's needed is a standard platform independent C/C++ header, which then allows a standard library (supplied by the compiler, platform dependent) that allows the use of OSF/Motif or whatever flavour of GUI you wish. Make this an ISO standard (stdgui.h instead of stdio.h), and you've put a lot of programmers out of work (or at least onto more productive tasks). I might add the same thing would be very useful for Ada. Just as we have TEXT_IO, why not GUI_IO? In fact, it would be _more_ useful for Ada, as it would then clear up 90% of the porting problem, rather than 20% (says he, picking representative figures out of thin air). -- aebrain@dynamite.com.au <> <> How doth the little Crocodile | Alan & Carmel Brain| xxxxx Improve his shining tail? | Canberra Australia | xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM abrain@cs.adfa.oz.au o OO*O^^^^O*OO o oo oo oo oo By pulling MAERKLIN Wagons, in 1/220 Scale