By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,484 Members | 1,041 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,484 IT Pros & Developers. It's quick & easy.

what is the difference in this pointers decalarition

P: n/a
what is the difference in this pointers decalarition ?

int *ptr[10];

and

int (*ptr)[10];

Feb 27 '06 #1
Share this Question
Share on Google+
14 Replies


P: n/a
One is an array of pointers while the other is a pointer to an array.
Example:

int *ptr[10];
int var1, var2;
ptr[0] = &var1;
ptr[1] = &var2;

......

int (*ptr)[10];
int multiDimensionalArray[5][10];

ptr = multiDimensionalArray;

Feb 27 '06 #2

P: n/a

relient wrote:
One is an array of pointers while the other is a pointer to an array.
Example:

int *ptr[10];
int var1, var2;
ptr[0] = &var1;
ptr[1] = &var2;

.....

int (*ptr)[10];
int multiDimensionalArray[5][10];

ptr = multiDimensionalArray;


Thank you relient

so how i can access array (multiDimensionalArray) with pointer( ptr ).

Feb 27 '06 #3

P: n/a
The same way you would with the multiDimensionalArray variable.

ptr[0][1] = 5;
- relient

Feb 27 '06 #4

P: n/a
relient wrote:
The same way you would with the multiDimensionalArray variable.

ptr[0][1] = 5;


*Please* quote what (and /who/) you're replying to. Many people can't
see previous posts, for various reasons. It's also possible to do it
via Google, if you click Show Options, and then Reply below the message
header. It's only one click more than Reply at the bottom of the
message, and will do everything for you.

--
BR, Vladimir

Some people live life in the fast lane.
You're in oncoming traffic.

Feb 27 '06 #5

P: n/a

Vladimir S. Oka wrote:
relient wrote:
The same way you would with the multiDimensionalArray variable.

ptr[0][1] = 5;


*Please* quote what (and /who/) you're replying to. Many people can't
see previous posts, for various reasons. It's also possible to do it
via Google, if you click Show Options, and then Reply below the message
header. It's only one click more than Reply at the bottom of the
message, and will do everything for you.

--
BR, Vladimir

Some people live life in the fast lane.
You're in oncoming traffic.


Yes, I forgot. I'm sorry.

- relient

Feb 27 '06 #6

P: n/a
Thank you very much.

relient

int (*ptr)[10]; ---> is a pointer to arrays ?.

Feb 27 '06 #7

P: n/a
int *ptr[10] refers to a ptr is an arrary of 10 pointers to an integer.

whereas int (*ptr)[10] refers to a ptr is a pointer to an array of 10
integers.

Feb 27 '06 #8

P: n/a
int *ptr[10] refers to a ptr is an arrary of 10 pointers to an integer.

whereas int (*ptr)[10] refers to a ptr is a pointer to an array of 10
integers.

Feb 27 '06 #9

P: n/a
code break wrote:
Thank you very much.

relient

int (*ptr)[10]; ---> is a pointer to arrays ?.

Thank you for what? Please follow Vladimir's advice.

--
Ian Collins.
Feb 27 '06 #10

P: n/a
code break wrote:
int (*ptr)[10]; ---> is a pointer to arrays ?.


It is a pointer to an array if 10 ints. As with any pointer in C, the
object pointed to by this pointer (i.e. the 'int[10]' array) might be a
standalone object, or it might be an element of larger array:

int (*ptr)[10];

int a[10];
ptr = &a;
/* 'ptr' points to a "standalone" array */

int b[10][10];
ptr = &b[5];
/* 'ptr' points to the 5th subarray in two-dimensional array */

--
Best regards,
Andrey Tarasevich

Feb 27 '06 #11

P: n/a
Andrey Tarasevich <an**************@hotmail.com> writes:
code break wrote:
int (*ptr)[10]; ---> is a pointer to arrays ?.


It is a pointer to an array if 10 ints. As with any pointer in C, the
object pointed to by this pointer (i.e. the 'int[10]' array) might be a
standalone object, or it might be an element of larger array:


Note that pointers to arrays are rarely useful. Usually the easiest
way to access an array is via a pointer to its first element; this has
the advantage of being able to deal with arrays of varying sizes.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 27 '06 #12

P: n/a
Keith Thompson wrote:
Andrey Tarasevich <an**************@hotmail.com> writes:
code break wrote:
int (*ptr)[10]; ---> is a pointer to arrays ?.


It is a pointer to an array if 10 ints. As with any pointer in C, the
object pointed to by this pointer (i.e. the 'int[10]' array) might be a
standalone object, or it might be an element of larger array:


Note that pointers to arrays are rarely useful. Usually the easiest
way to access an array is via a pointer to its first element; this has
the advantage of being able to deal with arrays of varying sizes.


I wouldn't put an equality sign between "can be avoided" and "rarely
useful". In my opinion, the technique of accessing with array through a
pointer to its first element should be restricted to situations when it
is really necessary to deal with arrays of varying sizes. In cases when
the array size is fixed (i.e. known at compile time) the preference
should be given to the more strongly typed approach: using pointer to
the entire array.

--
Best regards,
Andrey Tarasevich
Mar 2 '06 #13

P: n/a
Andrey Tarasevich <an**************@hotmail.com> writes:
Keith Thompson wrote:
Andrey Tarasevich <an**************@hotmail.com> writes:
code break wrote:
int (*ptr)[10]; ---> is a pointer to arrays ?.

It is a pointer to an array if 10 ints. As with any pointer in C, the
object pointed to by this pointer (i.e. the 'int[10]' array) might be a
standalone object, or it might be an element of larger array:


Note that pointers to arrays are rarely useful. Usually the easiest
way to access an array is via a pointer to its first element; this has
the advantage of being able to deal with arrays of varying sizes.


I wouldn't put an equality sign between "can be avoided" and "rarely
useful". In my opinion, the technique of accessing with array through a
pointer to its first element should be restricted to situations when it
is really necessary to deal with arrays of varying sizes. In cases when
the array size is fixed (i.e. known at compile time) the preference
should be given to the more strongly typed approach: using pointer to
the entire array.


I disagree. First, it's very common for array sizes not to be known
at compile time; very often, you don't know how big the array needs to
be until run time. Even if you have a fixed-size array, you might
need to pass it to a function that can deal with arrays of any size.

Dealing with arrays through element pointers is a common idiom. In
fact, array indexing is defined in terms of pointer arithmetic. With
pointers to arrays, it's to easy to get the syntax wrong, and to mix
up a pointer-to-array with a pointer-to-array-element.

If I really needed a pointer to a fixed-size array, I might wrap the
array in a structure.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Mar 2 '06 #14

P: n/a
Keith Thompson wrote:
...
I wouldn't put an equality sign between "can be avoided" and "rarely
useful". In my opinion, the technique of accessing with array through a
pointer to its first element should be restricted to situations when it
is really necessary to deal with arrays of varying sizes. In cases when
the array size is fixed (i.e. known at compile time) the preference
should be given to the more strongly typed approach: using pointer to
the entire array.
I disagree. First, it's very common for array sizes not to be known
at compile time; very often, you don't know how big the array needs to
be until run time.


That's true, but I don't see how it can work as an argument in this case.
Situation that allow the use of pointers to arrays are rare, but that might just
be a reason to give them special treatment.
Even if you have a fixed-size array, you might
need to pass it to a function that can deal with arrays of any size.
Yes, one can always do that. It just means that functions that are designed to
work with arrays of different size should have their parameters declared
accordingly. I'm not arguing with that, but this is beside the point.
Dealing with arrays through element pointers is a common idiom. In
fact, array indexing is defined in terms of pointer arithmetic.
Also true, but still not an argument.
With
pointers to arrays, it's to easy to get the syntax wrong, and to mix
up a pointer-to-array with a pointer-to-array-element.
It requires a certain level of discipline from the user, as does almost
everything in C language. Normally, the syntax will turn out right by itself,
because in situations that call for fixed-size arrays it makes sense to declare
a typedef-name for the array type. After that the function parameter
declarations will become simple and intuitive.

typedef int TData[10];
void foo(const TData* input, TData* output);

They will also appear more logical since it is a common idiom to pass
large[-ish] aggregates by pointer to the entire aggregate. Such parameter
declarations are invariant with regard to the concrete aggregate type, i.e. the
semantics of the parameter (pass-by-value vs pass-by-pointer) will not change if
the array is replaced with a structure. Also, things like 'sizeof' continue to
work "as expected". Additionally, it emphasizes the fact that the function is
specifically designed to work with arrays of one concrete size.

Of course, hiding array type behind a typedef-name doesn't hide it's real
nature. It doesn't become assignable, for example, which in general case
negatively impacts the generality of the code written in terms of the above
typedef-name.
If I really needed a pointer to a fixed-size array, I might wrap the
array in a structure.


In my opinion this alone is not enough to grant the use of a structure.

--
Best regards,
Andrey Tarasevich
Mar 2 '06 #15

This discussion thread is closed

Replies have been disabled for this discussion.