comma operator: keep away?

[Rich Neitzel]

In article <19378 at adm.BRL.MIL> Kemp at 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 at 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.





-------------------------------------------------------------------------------