454,435 Members | 1,499 Online
Need help? Post your question and get tips & solutions from a community of 454,435 IT Pros & Developers. It's quick & easy.

# Pass A 2-D, Statically Defined Array?

 P: n/a Is it possible to pass a 2-D, statically defined array? Here's a 1-D example that won't work: void foo() { int myArray[MAX_SIZE] ; bar(myArray); } void bar(int *arr) { arr[5]=arr[7]; } It won't work because myArray is statically defined. To make it work, you can change foo's bar() call to this: bar(&myArray[0]); Then it works fine! Any way to apply the same technique with a 2-D array? void foo() { int myArray[SIZE_A][SIZE_B] ; bar(??myArray??); } void bar(int **arr) { arr[5][3]=arr[2][4]; } One possible workaround is to define myArray as 1-D but use it as 2-D: void foo() { int myArray[SIZE_A*SIZE_B] ; bar(&myArray[0]); } void bar(int *arr) { arr[5*SIZE_B+3]=arr[2*SIZE_B+4]; } Kind-of inelegant, though. Thanks for any advice! --Darel Da******@gmail.com http://alienryderflex.com Jan 2 '07 #1
19 Replies

 P: n/a Da******@gmail.com wrote On 01/02/07 16:30,: Is it possible to pass a 2-D, statically defined array? Here's a 1-D example that won't work: void foo() { int myArray[MAX_SIZE] ; bar(myArray); } void bar(int *arr) { arr[5]=arr[7]; } It won't work because myArray is statically defined. In what way does it fail to "work?" (And what do you mean by "statically defined?" Whatever it is, it seems to have nothing to do with the "static" keyword or with "static storage duration.") To make it work, you can change foo's bar() call to this: bar(&myArray[0]); Then it works fine! Very strange. Take a fragment of nothing-obviously-wrong code, add an obvious error, and it "works fine," whatever that means. Any way to apply the same technique with a 2-D array? The "technique" of taking (apparently) correct code, adding an error, and declaring that it "works fine?" DarelRex, I think you'd eliminate a lot of confusion by posting some actual code instead of fragmentary paraphrases. As things stand, I do not know what problem you are having and cannot suggest a solution. -- Er*********@sun.com Jan 2 '07 #2

 P: n/a

 P: n/a On Tue, 02 Jan 2007 17:02:23 -0500, Eric Sosman wrote: >Da******@gmail.com wrote On 01/02/07 16:30,: >Is it possible to pass a 2-D, statically defined array?Here's a 1-D example that won't work:void foo() { int myArray[MAX_SIZE] ; bar(myArray); }void bar(int *arr) { arr[5]=arr[7]; }It won't work because myArray is statically defined. In what way does it fail to "work?" (And what do youmean by "statically defined?" Whatever it is, it seems tohave nothing to do with the "static" keyword or with "staticstorage duration.") >To make it work,you can change foo's bar() call to this: bar(&myArray[0]);Then it works fine! Very strange. Take a fragment of nothing-obviously-wrongcode, add an obvious error, and it "works fine," whateverthat means. In what way is the argument &myArray[0] any different than the argument myArray? Both evaluate to the address of myArray[0] with type pointer to int. Remove del for email Jan 3 '07 #4

 P: n/a On 2 Jan 2007 13:30:52 -0800, Da******@gmail.com wrote: >Is it possible to pass a 2-D, statically defined array? Yes >Here's a 1-D example that won't work: What do you mean by won't work. Do you get a compile time diagnostic? If so, what is it? >void foo() { int myArray[MAX_SIZE] ; bar(myArray); }void bar(int *arr) { arr[5]=arr[7]; }It won't work because myArray is statically defined. To make it work,you can change foo's bar() call to this: There is nothing static about myArray. Static refers to storage duration. myArray is an object with automatic storage duration. > bar(&myArray[0]); This is syntactically identical to the original code. Any C compiler is required to treat the two identically. >Then it works fine! Define works fine since it is no different. >Any way to apply the same technique with a 2-D array?void foo() { int myArray[SIZE_A][SIZE_B] ; bar(??myArray??); Remove the '?'. }void bar(int **arr) { Change the type of the parameter to int[SIZE_A][SIZE_B] or the equivalent int(*)[SIZE_B]. arr[5][3]=arr[2][4]; } The rule is: except when the operand of the sizeof and & operators, an expression with type array of T will evaluate to the address of the first element of the array with type pointer to T. Your 2-D array is an array of SIZE_A array of SIZE_B int. Therefore, the expression myArray evaluates to the address of myArray[0] with type pointer to array of SIZE_B int, which is the type of the second form of the parameter above. Remove del for email Jan 3 '07 #5

 P: n/a Barry Schwarz wrote: [given `int myArray[MAX_SIZE];'] In what way is the argument &myArray[0] any different than the argument myArray? Both evaluate to the address of myArray[0] with type pointer to int. This is Question 6.12 in the comp.lang.c Frequently Asked Questions (FAQ) list at http://c-faq.com/ . -- Eric Sosman es*****@acm-dot-org.invalid Jan 3 '07 #6

 P: n/a Eric Sosman [given `int myArray[MAX_SIZE];']In what way is the argument &myArray[0] any different than theargument myArray? Both evaluate to the address of myArray[0] withtype pointer to int. This is Question 6.12 in the comp.lang.c Frequently Asked Questions (FAQ) list at http://c-faq.com/ . Not really. 6.12 talks about the difference between arr and &arr (they differ in type). Barry was talking about the difference between arr and &arr[0] (there is none in most contexts, including the one being considered). -- Keith Thompson (The_Other_Keith) ks***@mib.org San Diego Supercomputer Center <* We must do something. This is something. Therefore, we must do this. Jan 3 '07 #7

 P: n/a Eric Sosman said: Barry Schwarz wrote: >[given `int myArray[MAX_SIZE];']In what way is the argument &myArray[0] any different than theargument myArray? Both evaluate to the address of myArray[0] withtype pointer to int. This is Question 6.12 in the comp.lang.c Frequently Asked Questions (FAQ) list at http://c-faq.com/ . No, it isn't. -- Richard Heathfield "Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk email: rjh at the above domain, - www. Jan 3 '07 #8

 P: n/a Wow, I didn't know a simple programming question was an invitation to abuse! I guess some people have no other source of self-worth than trying to belittle people who ask for help. But thanks to those who tried to answer politely. To clarify -- by statically defined I mean this: int myArray[SIZE] ; as opposed to dynamic, like so: int *myArray=malloc(sizeof(int)*SIZE) ; (or something like that) In the latter case, myArray can be passed to bar() no problem, but I have had serious problems with some C compilers trying to pass myArray in the former case. Those problems go away if I pass &myArray[0]. Can anyone back me up on this -- has anyone had similar experiences? (Common sense 101: If the answer is "yes", please reply, but if the answer is "no" don't post a nasty comment.) Thanks in advance, --Darel Da******@gmail.com http://alienryderflex.com Jan 3 '07 #9

 P: n/a Richard Heathfield wrote: Eric Sosman said: >Barry Schwarz wrote: >>[given `int myArray[MAX_SIZE];']In what way is the argument &myArray[0] any different than theargument myArray? Both evaluate to the address of myArray[0] withtype pointer to int. This is Question 6.12 in the comp.lang.c FrequentlyAsked Questions (FAQ) list at http://c-faq.com/ . No, it isn't. Oh, pfui. That'll teach me not to read overhastily and write while dozing off. (More likely it won't, and I'll just embarrass myself yet again ...) My apologies to DarelRex: Changing from foo(myArray) to foo(&myArray[0]) does not introduce an error, as I claimed. On the other hand, it doesn't fix anything either: it means, as Barry Schwarz pointed out, exactly the same thing and should make no difference at all. So I'll repeat my earlier request: Could we see some actual code and actual error messages, please? Debugging fragmentary "sort-of-likes" is an uncertain business, as I think I've demonstrated all too clearly ... -- Eric Sosman es*****@acm-dot-org.invalid Jan 3 '07 #11

 P: n/a Richard Heathfield said: ... I guess all the nasty comments you've received have been filtered out by my newsreader. Good. We must not be using the same newsreader -- your last post came through loud and clear on mine. Jan 3 '07 #12

 P: n/a Da******@gmail.com writes: Richard Heathfield said: >...I guess all the nasty comments you've received have been filtered out by mynewsreader. Good. We must not be using the same newsreader -- your last post came through loud and clear on mine. I don't recall seeing any "nasty" comments in this thread. Can you post message-ids of any posts you consider nasty? I suspect you're being overly sensitive, but I can't be sure of that unless I know just what you're referring to. In this newsgroup, we tend to point out each other's errors, and we do so unapologetically. (Most of us are grateful for these corrections.) Is that what you consider "nasty"? -- Keith Thompson (The_Other_Keith) ks***@mib.org San Diego Supercomputer Center <* We must do something. This is something. Therefore, we must do this. Jan 3 '07 #14

 P: n/a OK, here's the detail on this issue. I'm using Xcode (Panther release), which I believe uses some version of the gcc compiler, but I don't really know. However, I distinctly remember having this same problem with C long before there was such a thing as Xcode. Here's my simple test case. This is actual code, that I actually compiled and (if it compiled clean) actually ran! void foo() { int myArray[3][3]={{ 0, 1, 2 }, { 3, 4, 5 }, { 6, 7, 8 }} ; bar(myArray); } void bar(int **arr) { arr[2][1]=arr[0][2]; } When I compile this, I get a warning: "passing arg 1 of 'bar' from incompatible pointer type". So I changed the bar call to this: bar((int **) myArray); Now I get no warning, but the assignment statement inside the bar function terminates the app with this message: "Program received signal: 'EXC_BAD_ACCESS'" So I change the bar call to: bar(&myArray[0]); Then I get the warning again: "passing arg 1 of 'bar' from incompatible pointer type". So I change the call to this: bar((int **) &myArray[0]); Then I get no warning, but the assignment statement inside bar terminates again: "Program received signal: 'EXC_BAD_ACCESS'" So now I change the bar function to receive just a pointer to int, like so: (int *), and I change the bar call to: bar(&myArray[0][0]); And I have to change the assignment statement to calculate the 2-D indices: arr[2*3+1]=arr[0*3+2]; Once again the compiler gives me the warning ("passing arg 1 of 'bar' from incompatible pointer type"), so I change the bar call to: bar((int *) &myArray[0][0]); Voila! It finally works. And I have verified that it is reading the actual values from the array. But the assignment statement must use a calculated 2-D address, as described above. Now, I just ran all these tests today, so I *know* this problem is real. Please, anyone who knows something about it, post a reply if you have the time. Thanks much, Darel Da******@gmail.com http://alienryderflex.com Jan 4 '07 #15

 P: n/a Da******@gmail.com wrote: void foo() { int myArray[3][3]={{ 0, 1, 2 }, { 3, 4, 5 }, { 6, 7, 8 }} ; bar(myArray); } void bar(int **arr) { arr[2][1]=arr[0][2]; } void bar(int (*arr)[3]) { arr[2][1] = arr[0][2]; } -- pete Jan 4 '07 #16

 P: n/a Da******@gmail.com wrote: OK, here's the detail on this issue. I'm using Xcode (Panther release), which I believe uses some version of the gcc compiler, but I don't really know. However, I distinctly remember having this same problem with C long before there was such a thing as Xcode. Here's my simple test case. This is actual code, that I actually compiled and (if it compiled clean) actually ran! void foo() { int myArray[3][3]={{ 0, 1, 2 }, { 3, 4, 5 }, { 6, 7, 8 }} ; bar(myArray); } void bar(int **arr) { arr[2][1]=arr[0][2]; } When I compile this, I get a warning: "passing arg 1 of 'bar' from incompatible pointer type". [...] Aha! This one *is* a FAQ (in light of recent history, I double-checked). It's Question 6.18 at http://c-faq.com/ . -- Eric Sosman es*****@acm-dot-org.invalid Jan 4 '07 #17

 P: n/a Da******@gmail.com said: OK, here's the detail on this issue. I'm using Xcode (Panther release), which I believe uses some version of the gcc compiler, but I don't really know. However, I distinctly remember having this same problem with C long before there was such a thing as Xcode. Here's my simple test case. This is actual code, that I actually compiled and (if it compiled clean) actually ran! void foo() { int myArray[3][3]={{ 0, 1, 2 }, { 3, 4, 5 }, { 6, 7, 8 }} ; bar(myArray); } void bar(int **arr) { arr[2][1]=arr[0][2]; } When I compile this, I get a warning: "passing arg 1 of 'bar' from incompatible pointer type". Turn up your warning level. When I compile this, I get: foo.c:1: warning: function declaration isn't a prototype foo.c: In function `foo': foo.c:3: warning: implicit declaration of function `bar' foo.c: At top level: foo.c:5: warning: no previous prototype for `bar' foo.c:5: warning: type mismatch with previous implicit declaration foo.c:3: warning: previous implicit declaration of `bar' foo.c:5: warning: `bar' was previously implicitly declared to return `int' So I changed the bar call to this: bar((int **) myArray); Since myArray decays to &myArray[0] which is an int(*)[3], it would be better to change bar() to receive int(*)[3], or change myArray to be an array of int *, rather than an array of int[3], and point its members to the first elements of arrays of int[3]. It's unwise to pretend that something is an int ** when it clearly isn't. Now I get no warning, I do: foo.c:1: warning: function declaration isn't a prototype foo.c: In function `foo': foo.c:3: warning: implicit declaration of function `bar' foo.c: At top level: foo.c:5: warning: no previous prototype for `bar' foo.c:5: warning: type mismatch with previous implicit declaration foo.c:3: warning: previous implicit declaration of `bar' foo.c:5: warning: `bar' was previously implicitly declared to return `int' but the assignment statement inside the bar function terminates the app with this message: "Program received signal: 'EXC_BAD_ACCESS'" What app? There's no main() function! Yet again, I would ask that you provide a complete program that exhibits your problem, so that people can give you real, useful help. -- Richard Heathfield "Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk email: rjh at the above domain, - www. Jan 4 '07 #18

 P: n/a Keith Thompson said: Da******@gmail.com writes: >Richard Heathfield said: >>...I guess all the nasty comments you've received have been filtered out bymy newsreader. Good. We must not be using the same newsreader -- your last post came throughloud and clear on mine. I don't recall seeing any "nasty" comments in this thread. Can you post message-ids of any posts you consider nasty? <11**********************@i12g2000cwa.googlegroups .com> -- Richard Heathfield "Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk email: rjh at the above domain, - www. Jan 4 '07 #19

 P: n/a Eric Sosman said: Aha! This one *is* a FAQ (in light of recent history, I double-checked). It's Question 6.18 at http://c-faq.com/ . Thank you, Eric. That is excellent information, and it answers my question completely. Over and out, Darel Da******@gmail.com http://alienryderflex.com Jan 5 '07 #20

### This discussion thread is closed

Replies have been disabled for this discussion.