<html>
<body>
<font size=3>Perry,<br><br>
My first comment had nothing to do with whether C's 2-d arrays are
allocated contiguously in memory. I assume that they are, as was
implicit in my remark about "doing the stepping by
hand."<br><br>
My comment has to do with the assembly code that the C compiler generates
to access an element of the array. My much dog-eared edition of
K&R (1978) -- with a fair bit of faded yellow highlighting, all mine,
dating from 1983 -- says very clearly in the section
"Multi-dimensional Arrays" that "by definition, a
two-dimensional array is really a one-dimensional array, each of whose
elements is an array." Any compiler writer may thus choose to
store the addresses of the beginnings of the rows of an array in a
one-dimensional array, then recall and de-reference those pointers to get
the values of the two-dimensional array. In particular, this must
be valid:<br><br>
int a[9][9];<br>
*(a[1]+3) = 7 ;<br><br>
A C compiler must be perfectly happy to printf("a[1]=%d",a[1]),
or for that matter (a[1])[3]. You may consider this an
advantage. I am not so sure.<br><br>
I stipulate that the compiler writer MAY choose to compute a[1] -- a
pointer to real -- every time it appears, but I doubt there's language in
the standard that requires it, since only hardware characteristics say
which is more efficient.<br><br>
As for my final comment, Appendix A of K&R, "C Reference
Manual" says clearly that the [ ] in the array declarator may be
empty but if not it must contain a constant expression "whose value
is determinable at compile time." Clearly, one can not
separately compile a function that uses multidimensional array syntax --
not pointer syntax -- to return a specified value of an arbitrarily
dimensioned array. That can be easily done in Fortran, since the
array dimensions may be dummy arguments to the subroutines.
Recognizing them as variable array dimensions, the compiler sets aside
memory locations for their values, and writes code to set those locations
to the values pointed to by the dummy arguments on entry to the
subroutine. The Fortran standard requires this arcane behavior,
because it prohibits the real dimensions from changing between entry and
exit, though the reason for that is far from clear to me. It's
quite amusing really, that since the real array dimensions are decoupled
from the dummy argument value, they are effectively called by
value.<br><br>
Regarding RGB's lengthy response, I agree whole-heartedly that C should
not be expected to handle arrays perfectly, and that each language has
its own field of best application, such as C++ to GUI's, C for system
interfaces, and Fortran for array number crunching. For such things
wrappers are made.<br><br>
Sorry for being so obtuse originally.<br><br>
<br>
Mike<br><br>
<br>
At 09:05 AM 8/26/2008, you wrote:<br><br>
<blockquote type=cite class=cite cite="">"Michael H. Frese"
<Michael.Frese@NumerEx-LLC.com> writes:<br>
> C is not much better. I once worked a young computational
programmer<br>
> for almost a week to get him to prove to himself that a C
source<br>
> program couldn't walk through a 2-d array the hard way as fast as
a<br>
> Fortran source program unless the stepping was coded by
hand.<br><br>
I don't understand what that means. I've been programming in C for<br>
about 25 years, and I have known Fortran since the mid-1970s.<br><br>
> He didn't believe that a 2-d array in C is syntactically a 1-d
array<br>
> of pointers to 1-d arrays,<br><br>
He was right. You are just plain wrong.<br><br>
char foo[10][10]<br><br>
allocates 100 consecutive addresses in memory.<br><br>
In case you don't believe me, try out the following program:<br><br>
----------------------------------------------------------------------<br>
#include <stdio.h><br><br>
char foo[10][10];<br><br>
int main(int argc, char **argv)<br>
{<br>
<x-tab> </x-tab>int i,
j;<br>
<x-tab> </x-tab><br>
<x-tab> </x-tab>for (i =
0; i < 10; i++)<br>
<x-tab> </x-tab><x-tab>
</x-tab>for (j = 0; j
< 10; j++)<br>
<x-tab> </x-tab><x-tab>
</x-tab><x-tab>
</x-tab>
printf("%d\n", &(foo[i][j]));<br>
}<br>
----------------------------------------------------------------------<br>
<br>
It will print 100 consecutive integers, the addresses of the
character<br>
array elements.<br><br>
> and the row pointers must be fetched from memory!<br><br>
I call bull. That's just totally false. You clearly don't know how C<br>
works.<br><br>
> And separate compilation of functions with variable array<br>
> dimensions? I hear echoes of Kernighan and Ritchie laughing
with each<br>
> other "We don't need no steenking libraries with execution-time
array<br>
> dimensioning! We're system programmers here! Besides, if
somebody<br>
> needs that they'll use Fortran."<br><br>
Er, you can do that, too. Works just fine. What *are* you talking<br>
about?<br><br>
Perry<br>
_______________________________________________<br>
Beowulf mailing list, Beowulf@beowulf.org<br>
To change your subscription (digest mode or unsubscribe) visit
<a href="http://www.beowulf.org/mailman/listinfo/beowulf" eudora="autourl">
http://www.beowulf.org/mailman/listinfo/beowulf</a></font></blockquote>
</body>
</html>