what is the difference in this pointers decalarition

[code break]

what is the difference in this pointers decalarition ?

int *ptr[10];

and

int (*ptr)[10];

 

[relient]

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;

 

[code break]

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 ).

 

[relient]

The same way you would with the multiDimensionalArray variable.

ptr[0][1] = 5;


- relient

 

[Vladimir S. Oka]

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.

 

[relient]

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

 

[code break]

Thank you very much.

relient

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

 

[manoj]

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.

 

[manoj]

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.

 

[Ian Collins]

Thank you very much.

relient

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

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

 

[Andrey Tarasevich]

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 */

 

[Keith Thompson]

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.

 

[Andrey Tarasevich]

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.

 

[Keith Thompson]

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.

 

[Andrey Tarasevich]

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.