Velocity Reviews > Two dimensional array Question

# Two dimensional array Question

Ben Bacarisse
Guest
Posts: n/a

 05-10-2008
Joe Wright <(E-Mail Removed)> writes:
<snip>
> All true on the face of it but sizeof was not what was asked, it was
> assignment.

Yes, I know I took it out of context. It was deliberate because I
wanted to point out that context was critical. Maybe I complicated
matters and, if so, I am sorry.

--
Ben.

Ben Bacarisse
Guest
Posts: n/a

 05-11-2008
pete <(E-Mail Removed)> writes:

> Ben Bacarisse wrote:

<snip>
>> OK, but you'll have to help me if you think I've missed something. I
>> really do think I get it.
>>
>> I know you meant "in most expression contexts"

>
> I didn't mean that.
> I meant that given
>
> int arr[2][13], **p, i;
>
> then
>
> *p = arr[i];
>
> means exactly the same thing as
>
> *p = &arr[i][0];

Gotcha. You were making a very narrow point.

Sadly, you led me a little up the path I ended up running down.
Rather than stopping there, you went on to expand &arr[i][0] in stages
(without the *p = context) which I jumped on as implying a more
general equivalence.

If you'd kept the context and written:

"*p = &arr[i][0] means *p = &*(*(arr + i) + 0)

which can be simplified to

*p = (*(arr + i) + 0)
*p = *(arr + i)
*p = arr[i]

I hope I'd have kept out of it.

--
Ben.

Barry Schwarz
Guest
Posts: n/a

 05-11-2008
On May 9, 8:35*pm, mdh <(E-Mail Removed)> wrote:

> *I was in a hurry to get to work this am...so forgot to ask this.
> In a multidimensional array, one can simply drop the second []? *as in
> *p=arr[i] and this is legal?

Depending on the type of p. If arr is defined as T arr[N][M], then
for your code to be legal, p must be a T**. *p will then have type T*
and arr[i] will be converted to &arr[i][0] which is also of type T*.

Far more common is for p to be a T* and the assignment to read
p = arr[i].

mdh
Guest
Posts: n/a

 05-12-2008
On May 11, 4:17*am, Barry Schwarz <(E-Mail Removed)> wrote:
> On May 9, 8:35*pm, mdh <(E-Mail Removed)> wrote:
>
>
> Depending on the type of p. *If arr is defined as T arr[N][M], then
> for your code to be legal, p must be a T**. **p will then have type T*
> and arr[i] will be converted to &arr[i][0] which is also of type T*.
>
> Far more common is for p to be a T* and the assignment to read
> p = arr[i].

Well...I **think** I see it a little more clearly.
Although once admonished for writing code to figure things out, a weak
attempt follows.

#include <stdio.h>

int main (int argc, const char * argv[])
{
int i, j, k, l;
char arr [3][3] = {"One", "Two", "Lst"};
char *p;
char **q;

for ( i = 0; i < 3; i ++)
for ( j= 0; j < 3; j++)
{
p=&arr[i][j];
printf( "%p\n", p);
}

putchar('\n');

for ( k = 0; k < 3; k ++)
for ( l= 0; l < 3; l++)
{
p=arr[k];
q=&arr[k][l];
printf( "%s %s\n", p, q);
}
}
output:

0xbffff7cf
0xbffff7d0
0xbffff7d1
0xbffff7d2
0xbffff7d3
0xbffff7d4
0xbffff7d5
0xbffff7d6
0xbffff7d7

OneTwoLst OneTwoLst
OneTwoLst neTwoLst
OneTwoLst eTwoLst
TwoLst TwoLst
TwoLst woLst
TwoLst oLst
Lst Lst
Lst st
Lst t

Which I think says, as mentioned above, that the addresses are
contiguous. So at least that is an easy visual and conceptual concept
to comprehend.
And to repeat what you put far more elegantly, more to see if I am
understanding it,
char *p in the context of the declaration arr[m][n], is a "row"
and char **q, is a character?

Default User
Guest
Posts: n/a

 05-12-2008
mdh wrote:

> int main (int argc, const char * argv[])
> {
> int i, j, k, l;
> char arr [3][3] = {"One", "Two", "Lst"};

You do not reserve enough space for a null terminator. You will have
arrays of char but not strings in your array.

> char *p;
> char **q;
>
> for ( i = 0; i < 3; i ++)
> for ( j= 0; j < 3; j++)
> {
> p=&arr[i][j];
> printf( "%p\n", p);

You should cast p to void*.

> }
>
> putchar('\n');
>
> for ( k = 0; k < 3; k ++)
> for ( l= 0; l < 3; l++)
> {
> p=arr[k];
> q=&arr[k][l];
> printf( "%s %s\n", p, q);

You attempt to pass the non-strings when printf() is expecting strings.
will tell you very much.

Brian

mdh
Guest
Posts: n/a

 05-13-2008
On May 11, 8:16 pm, Richard Heathfield <(E-Mail Removed)> wrote:
>
> Writing code "to figure things out" is a two-edged sword. It can certainly
> be helpful for discovering how things *appear* to work, but it is a poor
> guide for discovering how things *must* work.

> > char arr [3][3] = {"One", "Two", "Lst"};

>
> Legal, but dangerous. Don't treat these arrays of char as if they were
> strings. They aren't.

OK..now let me show my total ignorance.

So, can multidim char arrays ever be treated as strings and would
this then be the correct intialization? char arr[] [] = "one, two";
And, for a regular (one dim) char array, would this be a string
intialization? char arr[]= "something" or the use of strcpy?

And, somewhat philosophically, a (one dim) char array is simply a
contiguous set of bytes. If one ? *knows* the array is NULL
terminated, then we can safely treat it as a string. But the *only*
way to know this is if it is correctly initialized in the first place.
Is this a fair way of looking at it?

> > p=&arr[i][j];
> > printf( "%p\n", p);

>
> Although the representations of char * and void * are required to be the
> same, it is generally wiser to insist on void * for %p:
>
> printf("%p\n", (void *)p);

I did read today about the need for a pointer to be cast to
void ...but is there a reason for this? Other than the language says
it should be so.

>
> You fell into the trap.

Yup!

> The easiest way to comprehend multidimensional arrays is to think of them
> as arrays of arrays. If you never try to breach the bounds of an object,
> all will be well. By treating arrays-of-arrays as if they were a single
> contiguous object (EVEN IF THAT IS TRUE), you're violating that principle

Yes..I like it...thanks.

mdh
Guest
Posts: n/a

 05-13-2008

>
> You attempt to pass the non-strings when printf() is expecting strings.
> will tell you very much.
>

Thanks Brian...I think I am beginning to understand this.Not quite
there yet...but getting closer!! Next onto function pointers!!!

mdh
Guest
Posts: n/a

 05-13-2008
Thanks Richard, as usual, for your insights.

Chris Torek
Guest
Posts: n/a

 05-13-2008
In article <(E-Mail Removed)>
Richard Heathfield <(E-Mail Removed)> wrote:
>... strcpy can never initialise anything, because initialisation is what
>you do to an object at the point where it is created.

In the sense of "an initializer" (as used in Standard C), yes.
However, one should be aware that many (perhaps even most?) people
also refer to the first assignment to something as its
"initialization", and then use the word "initialize" (or
"initialise") to describe what happens at that point.

That is:

void f(void) {
int i = 0;
int j;

... code that does not touch j ...
j = 0;
...
}

In Standard C terminology, the variable i has an initializer and
is initialized to 0. The variable j has no initializer and is not
initialized. The assignment "j = 0" is an ordinary assignment and
does not "initialize" j ... but in many/most people's terminology,
the assignment to j, which is its initial (i.e., first) assignment,
does "initialize" j.

In short, one must be careful with terminology, as the multiple
meanings of various words do confuse people.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: gmail (figure it out) http://web.torek.net/torek/index.html

Barry Schwarz
Guest
Posts: n/a

 05-17-2008
On May 11, 7:07*pm, mdh <(E-Mail Removed)> wrote:
>
> int main (int argc, const char * argv[])
> * * * * {

Did you throw the const in just to annoy people? Is that "signature"
properly documented on your system? How many other systems do you
think will support it?