From: jes@grendel.demon.co.uk (Jim Segrave)
Newsgroups: comp.lang.c
Subject: Re: multidimensional arrays as parameters
Date: 16 Oct 92 23:27:54 GMT
Organization: None
ReplyTo: jes@grendel.demon.co.uk
X-Mailer: cppnews $Revision: 1.18 $


In article <454@ulogic.UUCP> hartman@ulogic.UUCP (Richard M. Hartman) writes:

.. much discussion about using multi-dimensional arrays deleted
> >Isn't this in the FAQ?
> 
> Which begs the question, since the next array I pass may be [40][50],
> is there a more general approach?  
> 
> I think that you might be stuck adding dimension params to the function
> and doing the math yourself.  It might not be the ONLY way, and it is
> certainly inconvenient, but it should work.  e.g.:
> 
>     void fun2d(int *arr, int xsiz, int ysiz)
>     {
> 	...
>         *(arr+(ysiz*ycoord)+xcoord) = value;    /* arr[xcoord][ycoord]=value; */
> 	...
>     }
Yes - this is a general solution.
> Note: the order in which your machine (row-major or column-major) stores
> it's array-of-arrays will affect the math involved, it could also be:
> 
>         *(arr+(xsiz*xcoord)+ycoord) = value;    /* arr[xcoord][ycoord]=value; */
> 
> on some systems.
What??? Please don't post things like this which add confusion to an
area where people have enough troubles already. This posting follows on
from several others all discussing arrays of arrays. Any decent C
textbook will tell you that C does not have multi-dimensional arrays,
only arrays of arrays[of arrays...], so it is non-sensical and
misleading to talk of row major and column major order. Many of the
people who read this group are students or neophytes in C. Talking of
row/column major ordering re-enforces the erroneous impression that C
really does have multi-dimensional arrays - it does not.
int i[10][20] declares a ten element array each element of which is a 20
element array of ints. The arrays of (arrays of ints) in i[n] are in a
nice linear order i[0],i[1],...i[9]. Each of these arrays has 20 ints in
a nice linear order i[n][0],i[n][1],...i[n][19]. The ordering follows
from there - though see below - you are well advised not to speculate on
the relationship in storage locations between i[x][y] and i[w][z] if x
!= z. THe C language spec is deliberately non-commital about the just
how it goes about storing the spearate arrays. In particular:
>        When I need to find out how a system stores it's
> array-of-arrays I generally write a test program that defines and
> initializes a 5by5 array of int then walk an int* through from the
> start, printing the values as I go.  You'll either see all the values
> in row 1, then row 2, etc or all the values in column 1, column 2,
> etc.
The above is some bad advice. The C standard specifically forbids this
style of cavalier equivalencing of arrays. If you want Fortran...
Given my previous int i[10][20], the standard says that it is not valid
to attempt to reference i[0[20]  even though we all 'know' that it's the
same as i[1][0]. You can't walk a pointer to int through this array to
find out how it's stored!
 I will grant that on most implementaions of C, this sort of hackery
will work, but that does not alter the underlying truth - this is
specifically ruled off the turf by the C standard. I pretty sure that
you read comp.std.c - I'm sure I've seen postings by you in that group.
Have you not followed the thread on 'struct hacks'?
Please, please, please - don't add to the confusion about using
multi-dimensional arrays by implying that they are part of the language
- they aren't.
Please don't suggest poking about in the gubbins of the implementation
to find out how things are stored using a method which is explicitly
ruled out by the C standard.

> 
> Disclaimer: I have not compiled the above code and have not worked
> with multidimensional arrays for some time.  You may have to fiddle
> w/ the details (swap x & y?) to get it to work, but the concept
> should be valid on most systems.

It is invalid on every ANSI conformant system - even if it does (appear to)
work.
 
> q: would |void fun2d(int a[][])| be of any use (I don't *think* so...)
 
Only to check the spelling in compiler diagnostic messages. 
 
> 		-Richard Hartman
> 		hartman@ulogic.COM
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> "Smoke me a kipper, I'll be back for breakfast!"
> 
> 
--
Jim Segrave (Segrave Software Services)     jes@grendel.demon.co.uk
Newsgroups: comp.lang.c