Xref: utzoo comp.lang.fortran:781 comp.lang.c:10813 Path: utzoo!attcan!uunet!husc6!mailrus!ames!ll-xn!mit-eddie!bloom-beacon!mcgill-vision!mouse From: mouse@mcgill-vision.UUCP (der Mouse) Newsgroups: comp.lang.fortran,comp.lang.c Subject: Re: Should I convert FORTRAN code to C? Keywords: language conversions, FORTRAN, c Message-ID: <1171@mcgill-vision.UUCP> Date: 20 Jun 88 08:22:37 GMT References: <2742@utastro.UUCP> <20008@beta.UUCP> <10655@agate.BERKELEY.EDU> Organization: McGill University, Montreal Lines: 45 In article <10655@agate.BERKELEY.EDU>, jerry@violet.berkeley.edu ( Jerry Berkman ) writes: >> [C vs FORTRAN] > C is missing many useful intrinsics. I have trouble taking a > language seriously for numeric computation if the language doesn't > even know about absolute values, e.g.: x = abs(x); or signed > numbers, e.g. x = +5; Both statements are illegal in C. Not so. The first one is perfectly legal; any compiler that won't accept it is broken. The second one is legal under the dpANS (or at least in K&R V2), though it used to be illegal. (Why do we need a unary plus operator anyway? I never missed it.) > [ i = j**k and y = x**6 ] How do you express link->next->chain = vec[i++]; in FORTRAN? Why try to create a war of features? It sounds as though your sort of work is better expressed in FORTRAN. Please stick to FORTRAN, then, and stop complaining about C. You aren't complaining about how Snobol makes it difficult and slow to do what you want to do, are you? > Actually, C does not have a concept of intrinsic at all. It does under the dpANS, or very close to it. If we say, for example, #includex = sqrt(y); then we are justified in believing the sqrt() routine to be the math library routine. > For that matter, since sqrt() is a FORTRAN intrinsics, I get an error > message from any decent FORTRAN compiler for sqrt(integer). None > from C of course (running lint is a hassle). In other words, you recognize that you have such a checking feature available, but using it is too much trouble, so you complain about the lack of checking. Riiight. (I certainly can't see the hassle in running lint; just say "lint" instead of "cc"....) der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu