[Beowulf] Stroustrup regarding multicore

[Perry E. Metzger]

"Michael H. Frese" <Michael.Frese at NumerEx-LLC.com> writes:
> 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."

That was not what I got from your comment, but I'll take your word for
what you meant.

> 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."

That's high level semantic definition speak. It has nothing to do with
what sort of code the compiler turns out.

Syntactically, foo[a][b] looks like you have an array of arrays, since
you're applying the [] operator twice. However, the compiler does
whatever the heck it damn well pleases so long as the program runs the
same way, and no compiler does what you suggest. I've read a lot of
output machine code, and I've yet to see it done "badly".

> 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.

They can also choose to compile into Visual Basic and interpret
it. Indeed, if you read the Fortran spec, it permits you to compile
Fortran into Visual Basic and interpret it. Does anyone do that?
No. Should we fault Fortran as a language for the fact that the spec
does not specifically prohibit compilation into Visual Basic and
interpretation? Clearly not.

> In particular, this must be valid:
>
> int a[9][9];
> *(a[1]+3) = 7 ;

Who cares?

> 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.

It is neither an advantage nor a disadvantage.

> I stipulate that the compiler writer MAY choose to compute a[1] -- a
> pointer to real -- every time it appears,

Actually, since you've declared "int a[9][9]" it would be a pointer to
an array of ints. It is NOT a pointer to an int. BTW, the semantics
get VERY sticky here once you start playing these games -- it matters
a lot if you're talking about the use of the syntax in an rvalue or an
lvalue context and the specific declarations used.

> 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."

That's over 20 years old. In fact, it has not been the case for some
years. Please read an actual standards document, not K&R. Using a
variable in the declaration of an array inside a function, for
example, is perfectly valid these days, and C had syntax for some time
for passing variable sized multi-dimensional arrays to functions.

> Clearly, one can not separately compile a function that uses
> multidimensional array syntax

You're years behind the standards documents. Please read them.

> 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.

I see no advantage of Fortran for number crunching. It has strictly
fewer features for the purpose than C does. I'll respond to RGB later.

Perry