Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!stout!thor From: thor@stout.ucar.edu (Rich Neitzel) Newsgroups: comp.unix.questions Subject: Re: comma operator: keep away? Message-ID: <3120@ncar.ucar.edu> Date: 1 May 89 17:02:48 GMT References: <19378@adm.BRL.MIL> Sender: news@ncar.ucar.edu Reply-To: thor@stout.UCAR.EDU (Rich Neitzel) Organization: Field Observing Facility, NCAR, Boulder, CO Lines: 87 In article <19378@adm.BRL.MIL> Kemp@DOCKMASTER.NCSC.MIL writes: > >Arrays: > Although C has an array notation, it is not used very effectively. I >don't know of any C compilers that do array bounds checking (which does >not mean that none exist, but they are not on the machines I use). >Fortran programmers take such checking for granted. BTW, on all Fortran compilers I've ever used, bounds checking is a compiler option, typically NOT a default option. Certainly when I used to write realtime programs for RSX-11M no one used the bounds checking. Not something taken for granted. > In addition, C programmers use the *p++=*q++ construct to copy an array >because historically C compilers have been too stupid to optimize >"p[i] = q[i]". Sorry, but looking at the assembler output for several Fortran compilers versus C compilers on the same machine, I find that Fortran compilers are equally "too stupid to optimize" this construct. Alas, for do i = 1, 100 for (i = 0; i < 100; i++) j(i) = k(i) j[i] = k[i]; 10 continue virtually the same assembler output was generated for both languages. If you want "smart", C is better here, since it let's the programmer optimize "around" the "dumb" compiler. Besides, if one wants to do a straight copy between two arrays, then j(1:100000) = k(1:100000) vs. bcopy(k,j,sizeof(k); In this case, for large upper bounds the C form is more efficient and certainly less data-dependent. > >Fortran includes I/O within the language definition, which allows >the compiler to detect errors that C compilers can't. Granted, but there are times when I need to "violate" the rules. For example, I once needed to print out the bit patterns for 32 bit floating point numbers. In C this was simple and easy to follow: printf("%g = %x\n",float,float); In Fortran it would require double declarations and equivalences and be less clear (at least to me :-)). >Strings: > Fortran strings are represented by a pointer and a length; C strings ^^^^^^^^^^^^ >are just a pointer, with a null byte representing the end of the string. >Now what kind of a scuzzy, data-dependent, low-level hack is that? In my humble opinion it is Fortran that is data dependent here. Try finding out how big the actual string data is versus the amount of storage allocated for the maximum size. Most Fortran compilers I've used have initialized strings with blanks! Since these are often significant characters in a string, how do you finds the end of valid data? That's right, you do it yourself. Now you need a variable to keep track of the end of data index. And as for parsing, tell me what Fortran routine can do anything similar to strtok? Gosh, you mean I have to have separate strings big enough to hold the maximum exspected character size for every parsed item? Nope, I believe it's Fortran that data- dependent. > There indeed may be no objective reality to the term "high level", but Agreed, but it seems to me that the term is used to distingish languages like C and Fortran from assembler. I would have a hard time being convinced that C is not higher level is those terms. ------------------------------------------------------------------------------- Richard Neitzel National Center For Atmospheric Research thor@thor.ucar.edu Torren med sitt skjegg Thor with the beard lokkar borni under sole-vegg calls the children to the sunny wall Gjo'i med sitt shinn Gjo with the pelts jagar borni inn. chases the children in. -------------------------------------------------------------------------------