question about pointer define

W

Wonder

Hello,

I'm confused by the pointer definition such as int *(p[3]);

It seems if the parenthesis close p[3], it defines only 3 integers. The
star
is just useless. It can be showed by my program:

int main()
{
int *(p[3]);
// cout << *p[0] << "\t" << *p[1] << "\t" << *p[2] << endl;
cout << &p[0] << "\t" << &p[1] << "\t" << &p[2] << endl;
cout << p[0] << "\t" << p[1] << "\t" << p[2] << endl;
}

The program can be compiled on cygwin linux by g++ and run, the output
is:

0x22efb0 0x22efb4 0x22efb8
0x76c 0xffffffff 0x22efc8

If you delete the * in the definition, define int (p[3]); the second
line
will be:

1900 -1 2289608

Which is exactly the decimal numbers of the the previous program.

The second line is comment-out, coz it'll be core dumped if you want to
get
the content of the pointer.

Could someone explain what's going on here? Thanks.
 
E

Emmanuel Delahaye

W

Wonder

i'm just using cout to output. It has nothing to do with the nature of
the question here.
I'm new here, don't know we have to write strict C code.
 
I

Irrwahn Grausewitz

Wonder said:
I'm confused by the pointer definition such as int *(p[3]);

It seems if the parenthesis close p[3], it defines only 3 integers.

No. p is an array of three pointers to int.
The star is just useless.

Definitely not. The parentheses are.
It can be showed by my program:

int main()
{
int *(p[3]);
// cout << *p[0] << "\t" << *p[1] << "\t" << *p[2] << endl;
<snip>

This is by no means a C program. Either rewrite in C, or take this to
comp.lang.c++, please.

Best regards
 
W

Wonder

i don't think the elements in p are pointers, coz you even can't access
*p, i=0,1,2

if you make the parentheses close *p, or just erase parentheses, such
as
int (*p)[3] or int *p[3]

no problem, it's the definition of an array of three pointers to int.

BTW: is there a rule say that only C program can be written here, even
though the question is about C in nature?

Thanks.
 
J

John Bode

Wonder said:
Hello,

I'm confused by the pointer definition such as int *(p[3]);

It's the same as

int *p[3];

i.e., a 3-element array of pointers to int.
It seems if the parenthesis close p[3], it defines only 3 integers. The
star
is just useless.

The '*' indicates that p is an array of pointers to int, instead of
just an array of int.
It can be showed by my program:

int main()
{
int *(p[3]);
// cout << *p[0] << "\t" << *p[1] << "\t" << *p[2] << endl;
cout << &p[0] << "\t" << &p[1] << "\t" << &p[2] << endl;
cout << p[0] << "\t" << p[1] << "\t" << p[2] << endl;
}

The program can be compiled on cygwin linux by g++ and run, the output
is:

0x22efb0 0x22efb4 0x22efb8
0x76c 0xffffffff 0x22efc8

If you delete the * in the definition, define int (p[3]); the second
line
will be:

1900 -1 2289608

Which is exactly the decimal numbers of the the previous program.

Right. What's happening is that the contents of p are uninitialized,
so p[0] through p[2] contain random bit strings, and these random bit
strings happened to be the same between the two runs. In the first
case, where p is declared as

int *(p[3]);

each element of p is of a *pointer* type, so the output is formatted to
reflect that (i.e., as hex values corresponding to a virtual memory
address). In the second case, where p is declared as

int (p[3]);

each element is of an *int* type, and the output is formatted to
reflect that.
The second line is comment-out, coz it'll be core dumped if you want to
get
the content of the pointer.

Right, because without proper initialization, p[0] through p[2] don't
point anywhere meaningful.
Could someone explain what's going on here? Thanks.

Basically, for any type T and declarator foo,

T *(foo);

is the same as

T *foo;
 
M

Martin Ambuhl

Wonder said:
Hello,

I'm confused by the pointer definition such as int *(p[3]);

It seems if the parenthesis close p[3], it defines only 3 integers.
Wrong.

The star is just useless.
Wrong.

It can be showed by my program:

You program shows nothing. It is nothing but a bunch of syntax errors.
If you had posted it to <instead, it would still be
garbage: no inclusion of needed the header file, no specification of the
needed namespace qualification.
int main()
{
int *(p[3]);
// cout << *p[0] << "\t" << *p[1] << "\t" << *p[2] << endl;
cout << &p[0] << "\t" << &p[1] << "\t" << &p[2] << endl;
cout << p[0] << "\t" << p[1] << "\t" << p[2] << endl;
}

The program can be compiled on cygwin linux by g++

Which is not a C compiler, therefore not topical in <
And it won't compile under g++ if you invoke g++ with appropriate
specification of diagnostics and of the standard used.

[...]
Could someone explain what's going on here? Thanks.

You're an idiot.
 
M

Martin Ambuhl

Wonder said:
i'm just using cout to output. It has nothing to do with the nature of
the question here.
I'm new here, don't know we have to write strict C code.

Your code is not C. It is not loose C; it is not strict C; it is not
GNU C. It is in a different language.
 
W

Wonder

Thanks a lot for your kind reply.

Now the problem goes to the difference between
int (*p)[3];
int *p[3];
int *(p[3]);

As you said, the second and the third are same. You are right, for
both, the *p will give a core dump. However, the first one just give
the values of the elements, even though I didn't initialize anything.

int main()
{
int (*p)[3];
cout << *p[0] << "\t" << *p[1] << "\t" << *p[2] << endl;
cout << &p[0] << "\t" << &p[1] << "\t" << &p[2] << endl;
cout << p[0] << "\t" << p[1] << "\t" << p[2] << endl;
}
The output is:
440 -1869574000 -1869574000
0x6101cf3e 0x6101cf4a 0x6101cf56
0x6101cf3e 0x6101cf4a 0x6101cf56

Another strange thing is the second line and third line are same in
this case.
 
W

Wonder

I didn't copy & paste the header coz I thought it had nothing to do
with the question itself, and I don't want to waste too many lines.

You just show the rudeness which should not represent the spirit of
comp.lang.c.
 
J

John Bode

Wonder said:
i don't think the elements in p are pointers, coz you even can't access
*p, i=0,1,2


Because you haven't initialized them to point anywhere meaningful yet.
If you had done something like:

int x, y, z;
int *(p[3]) = {&x, &y, &z};

or
int *(p[3]);
p[0] = &x;
p[1] = &y;
p[2] = &z;

or even

p[0] = malloc(sizeof *p[0]);
p[1] = malloc(sizeof *p[1]);
p[2] = malloc(sizeof *p[2]);

*then* you could dereference each element.
if you make the parentheses close *p, or just erase parentheses, such
as
int (*p)[3] or int *p[3]

no problem, it's the definition of an array of three pointers to int.

No. Those two declarations do entirely different things:

int (*p)[3]; // p is a pointer to a 3-element array of int
int *p[3]; // p is a 3-element array of pointer to int

In the case of

int *(p[3]);

or

int (*p[3]);

the parentheses are redundant and unnecessary; they do not add anything
to the declaration, and are the same as int *p[3]. So remember:

int p[3]; // p is a 3-element array of int;
int *p[3]; // p is a 3-element array of pointer to int,
int *(p)[3]; // same as above
int *(p[3]); // same as above
int (*p[3]); // same as above
int (*p)[3]; // p is a pointer to a 3-element array of int
BTW: is there a rule say that only C program can be written here, even
though the question is about C in nature?

Don't assume that everyone who knows C also knows C++ as well; it's
kind of like asking a question about Latin but using French to
illustrate the problem. C and C++ are just different enough that using
one to ask questions about the other could lead to misunderstandings
and mistakes.
 
I

Irrwahn Grausewitz

[ about int *(p[3]); ]

Please preserve some context when you reply.
i don't think the elements in p are pointers,

They are. Just read the definition inside out, following the
precedence rules:

p p is ...
p[3] ... an array of three elements ...
(p[3]) ... (the ()s (are (just (noise)))) ...
*(p[3]) ... of pointers ...
int *(p[3]) ... to int. QED.
coz you even can't access
*p, i=0,1,2


But only because you didn't fill the array with sensible values.
if you make the parentheses close *p, or just erase parentheses, such
as
int (*p)[3] or int *p[3]

no problem, it's the definition of an array of three pointers to int.

Err, yes for the latter, no for the former:

p p is ...
(*p) ... a pointer ...
(*p)[3] ... to an array of three ...
int (*p)[3] ... ints.

It seems you're in dire need of a good C textbook.
BTW: is there a rule say that only C program can be written here, even
though the question is about C in nature?

Only C programs are of C in nature. ;-)

In other words: if you post code here, make sure it's C.
Additionally, you might want to follow the links in my signature
for an intersting reading.

Best regards
 
W

Wonder

p p is ...
(*p) ... a pointer ...
(*p)[3] ... to an array of three ...
int (*p)[3] ... ints.

Thanks a lot! Your method is very useful.
In other words: if you post code here, make sure it's C.
I rewrite the program in pure C, here it is:

#include <stdio.h>
int main()
{
int (*p)[3];
/* printf("%x\t%x\t%x\n",*p[0],*p[1],*p[2]); */
printf("%x\t%x\t%x\n",p[0],p[1],p[2]);
printf("%x\t%x\t%x\n",&p[0],&p[1],&p[2]);
}

And I recompiled it by gcc under cygwin. The output is:
4 10 1c
4 10 1c

The first printf would cause core dump, but now I can understand it if
here p is a pointer to an int array which has 3 elements.
My question is why the second and third printf give the same result,
seems p is same as &p here.
Thanks.
 
J

John Bode

Wonder said:
Thanks a lot for your kind reply.

Now the problem goes to the difference between
int (*p)[3];
int *p[3];
int *(p[3]);

As you said, the second and the third are same. You are right, for
both, the *p will give a core dump. However, the first one just give
the values of the elements, even though I didn't initialize anything.

int main()
{
int (*p)[3];
cout << *p[0] << "\t" << *p[1] << "\t" << *p[2] << endl;
cout << &p[0] << "\t" << &p[1] << "\t" << &p[2] << endl;
cout << p[0] << "\t" << p[1] << "\t" << p[2] << endl;
}
The output is:
440 -1869574000 -1869574000
0x6101cf3e 0x6101cf4a 0x6101cf56
0x6101cf3e 0x6101cf4a 0x6101cf56

Another strange thing is the second line and third line are same in
this case.


IIRC, dereferencing an invalid or NULL pointer invokes undefined
behavior, meaning any output you get will be suspect.

As a matter of habit, I explicitly initialize pointers to NULL or a
valid memory location when I declare them, just to avoid these kinds of
problems.
 
K

Keith Thompson

Wonder said:
I didn't copy & paste the header coz I thought it had nothing to do
with the question itself, and I don't want to waste too many lines.

It's (almost) always best to post a small, complete, working,
self-contained program, something that the rest of us can
cut-and-paste and try for ourselves. If your program uses printf(),
add the required "#include <stdio.h>".

A missing include directive can cause unpredictable problems, problems
that your compiler won't necessarily diagnose. If you post what
appears to be an incomplete program, it's always possible that the
problem is in the part you didn't post. (If you knew enough to be
absolutely sure that that's not the case, you wouldn't be asking us
about it.)

Be sure to cut-and-paste the exact code that you compiled. If you
manually transcribe it, you're likely to introduce errors, and we'll
have no way of guessing where the real problem is if we can't see your
actual code.

And yes, posting C++ to comp.lang.c is in appropriate. Some of us
might happen to know what "cout << endl" means, but some of us may
not.

You're using groups.google.com, which unfortunately makes it far too
easy to post improperly. Don't assume that your readers can easily
see the article to which you're replying. Include enough quoted text
so someone can read each followup on its own, post your new text
*after* any quoted text, and provide proper attributions so we can
tell who said what. There is a way to do this (and this has been
posted here hundreds of times):

If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.

Finally, we get a lot of people coming here and making these same
mistakes. For each new poster, it's the first time; for us regulars,
it's the same thing over and over and over again. Sometimes the
frustration boils over a bit. The best solution is for new posters to
follow the newsgroup for a while, or browse the archives, to get an
idea of how things are done. Unfortunately, there doesn't seem to be
a good way to get the message out.
 
E

E. Robert Tisdale

Wonder said:
You just show the rudeness
which should not represent the spirit of comp.lang.c.

It doesn't.
You have just met some of our indigenous trolls.
They pounce on every new subscriber.
You must learn to recognize them and ignore them.
 
K

Keith Thompson

Wonder said:
p p is ...
(*p) ... a pointer ...
(*p)[3] ... to an array of three ...
int (*p)[3] ... ints.

Thanks a lot! Your method is very useful.
In other words: if you post code here, make sure it's C.
I rewrite the program in pure C, here it is:

#include <stdio.h>
int main()
{
int (*p)[3];
/* printf("%x\t%x\t%x\n",*p[0],*p[1],*p[2]); */
printf("%x\t%x\t%x\n",p[0],p[1],p[2]);
printf("%x\t%x\t%x\n",&p[0],&p[1],&p[2]);
}

And I recompiled it by gcc under cygwin. The output is:
4 10 1c
4 10 1c

The first printf would cause core dump, but now I can understand it if
here p is a pointer to an int array which has 3 elements.
My question is why the second and third printf give the same result,
seems p is same as &p here.


Let's try a modified version of your program.

#include <stdio.h>
#include <stdlib.h>
int main()
{
int (*p)[3];
p = malloc(sizeof *p);
if (p == NULL) {
exit(EXIT_FAILURE);
}
printf("p[0] = %p\n", (void*)p[0]);
printf("&p[0] = %p\n", (void*)&p[0]);
free(p);
return 0;
}

On one implementation, I get:

p[0] = 0x460210
&p[0] = 0x460210

As we've established, p is a pointer to an array of 3 ints.

You didn't initialize p, so its value is garbage. Any attempt to look
at whatever it points to invokes undefined behavior (I got a segmentation
fault). I've corrected this with the malloc() call.

The correct format for printing a pointer value is "%p", not "%x".
The "%p" format expects an argument of type void*; the casts are
necessary (even though you may be able to get away without them).

The prefix to an indexing operator [] is actually a pointer. If it's
the name of an array, as in
int arr[10];
arr[5];
the array name is implicitly converted to a pointer to its first
element. Since p is already a pointer, no such conversion is
necessary.

Remember that, by definition, x[y] is equivalent to *(x+y). In this
case, p[0] is equivalent to *(p+0), which is equivalent to *p. So the
expression p[0] gives you the thing that p points to, which happens to
be an array of 3 ints.

So p[0] is an array of 3 ints. In most contexts, an expression of
array type is implicitly converted to a pointer to its first element.
So in the printf() statement, p[0] is converted to a pointer-to-int,
and its value happens to be 0x460210. (Actually, it's pseudo-random
garbage, but we'll leave that aside for now.)

Note that we considered this conversion rule in two different
contexts. For p, the prefix to the indexing operator, the rule
doesn't apply, because p is already a pointer (to an array of 3 ints).
For p[0], an array of 3 ints, the rule does apply, and it's converted
to a pointer-to-int.

In the second printf, we apply the "&" (address-of) operator to p[0].
This is one of the contexts in which the conversion to pointer
*doesn't* take place. (Another is the operand of the sizeof
operator.) So &p[0] is the address of an array-of-3-ints. p[0] and
&p[0] have different types, but they yield the same raw pointer value
when converted to void* and printed with "%p".

And in your original program, p[1] actually refers to *another* array
of 3 ints, the second element of the array of arrays-of-3-ints to
which p points. In my version of your program, I only allocated
enough memory for a single array-of-3-ints; if I wanted to play with
p[1], I'd have to allocate more memory.

This all seems confusing because, frankly, it is. I went down a
couple of blind alleys while writing this, and I'm not at all certain
that there are no errors in what I've written.

There really aren't many cases where it makes sense to have a pointer
to an array of 3 ints. Usually it makes much more sense to have a
pointer to int, which can be used to access an array of ints. If you
really need an array of items, where each item contains 3 ints, you
might be better off wrapping the array-of-3-ints in a struct and
declaring a pointer to the struct type. Even if you can keep the
complications of a pointer-to-fixed-size-array-of-whatever straight in
your head, the next person to read your code may not be able to.

For a better general understanding of the relationship between arrays
and pointers, read section 6 of the C FAQ,
<http://www.eskimo.com/~scs/C-faq/faq.html>. (In fact, read the whole
thing if you haven't already.)

And before assuming that everything I've written here is correct, wait
a while until the other regulars have had a chance to pick it apart.
 
J

Jack Klein

i'm just using cout to output. It has nothing to do with the nature of
the question here.
I'm new here, don't know we have to write strict C code.

Please provide context when you follow-up or reply to a post. There
have been any number of posts around here explaining how to do this
properly using the broken Google groups, or get yourself a real
newsreader.

The issue about C++ code is this: your sample program is written in
C++, not in C. Your original question was about the meaning of the
declaration 'int *(p[3]);'. We cannot answer that question here in
the context of C++, only in the context of C, which does not apply to
your sample program.

Whether the meaning of the declaration in C++ is the same as it is in
C is a matter for comp.lang.c++, since C does not define any
compatibility with C++. It is C++, rather, that defines backwards
compatibility with C. The C++ language standard incorporates parts of
an older, out-of-date version of the C standard, not vice-versa.

So while posters in this group could explain what the declaration
means in C, that is not necessarily what it means in your C++ (or Java
or C# of FORTRAN or ADA) program.
 
M

Malcolm

Wonder said:
I'm confused by the pointer definition such as int *(p[3]);

It seems if the parenthesis close p[3], it defines only 3 integers. The
star
is just useless. It can be showed by my program:
Everyone else is also confused, except maybe a few C rules lawyers.

The problem is that C allows you to define pointers to complex compound
types, such as arrays of arbitrary dimensions. The syntax very rapidly
becomes non-human understandable.

Here we have a pointer to an array of three integers. The declaration int
*p[3] would be an array of three pointers to an integer.
However under the bonnet a pointer to an array of three integers and a
pointer to an integer (which may have other integers follwing it
contiguously in memory) is the same. To avoid the confusion that results, a
wise C programmer will always use a plain int *, and specify in the comment
above the function if necessary that the pointer must point to exactly three
integers, or to a list of triplets if that is the intention.
 
K

Keith Thompson

E. Robert Tisdale said:
It doesn't.
You have just met some of our indigenous trolls.
They pounce on every new subscriber.
You must learn to recognize them and ignore them.

ERT himself is our most persistent indigenous troll. He has a long
history of posting misinformation.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Members online

No members online now.

Forum statistics

Threads
474,169
Messages
2,570,919
Members
47,459
Latest member
Vida00R129

Latest Threads

Top