Issue
Why is f.e. int arrayp[]
the same as int* arrayp
, as parameter in the definition/declaration of a function?
int* foo(int arrayp[]){}
A pointer to the first element of an int
array passed as argument in the caller.
Like:
#include <stdio.h>
int* foo (int arrayp[]);
int main(void)
{
int a[] = { 10,5,4,2,1 };
int *p;
p = foo(a);
printf("%d",*p);
return 0;
}
int* foo(int arrayp[])
{
*arrayp = 0;
return arrayp;
}
Why is int arrayp[]
a pointer to the first element of an array of type int
? IMHO I think this is very confusing. Some people may think that they passing an entired array (pass by value) with this expression.
Solution
In function parameter types, arrays are implicitly adjusted to the pointer they would decay to.
Thus, these function declaration pairs, for example, are compatible:
void foo(int a[]);
void foo(int *a); //compatible declaration
void bar(int a[][2][3]);
void bar(int (*a)[2][3]); //compatible declaration
Dennis Ritchie (the language author) explains this confusing rule in https://www.bell-labs.com/usr/dmr/www/chist.html
Moreover, some rules designed to ease early transitions contributed to later confusion. For example, the empty square brackets in the function declaration
int f(a) int a[]; { ... } are a living fossil, a remnant of NB's way of declaring a pointer; a is, in this special case only, interpreted in C as a pointer. The notation survived in part for the sake of compatibility, in part under the rationalization that it would allow programmers to communicate to their readers an intent to pass f a pointer generated from an array, rather than a reference to a single integer. Unfortunately, it serves as much to confuse the learner as to alert the reader.
(Note: Chist.html uses a K&R style function definition. A prototyped equivalent of the above function definition would be int f( int a[]){ ... }
.)
In short, the rule exists mainly to ease transition from B to C and to allow the programmer to signal to the reader that a pointer to the first element of an array is expected, rather than just a pointer to a single element (and do so without having to use a comment).
Function-typed parameters are also adjusted to pointers in a similar way.
void takeFuncPtr(void Func(void));
void takeFuncPtr(void (*Func)(void)); //compatible declaration
A perhaps more deeper question would be "why do arrays decay to pointers at all in C"?. The linked document provides an answer to that question as well:
... These semantics represented an easy transition from B, and I experimented with them for some months. Problems became evident when I tried to extend the type notation, especially to add structured (record) types. Structures, it seemed, should map in an intuitive way onto memory in the machine, but in a structure containing an array, there was no good place to stash the pointer containing the base of the array, nor any convenient way to arrange that it be initialized. For example, the directory entries of early Unix systems might be described in C as
struct { int inumber; char name[14]; };
I wanted the structure not merely to characterize an abstract object but also to describe a collection of bits that might be read from a directory. Where could the compiler hide the pointer to name that the semantics demanded? Even if structures were thought of more abstractly, and the space for pointers could be hidden somehow, how could I handle the technical problem of properly initializing these pointers when allocating a complicated object, perhaps one that specified structures containing arrays containing structures to arbitrary depth? The solution constituted the crucial jump in the evolutionary chain between typeless BCPL and typed C. It eliminated the materialization of the pointer in storage, and instead caused the creation of the pointer when the array name is mentioned in an expression. The rule, which survives in today's C, is that values of array type are converted, when they appear in expressions, into pointers to the first of the objects making up the array.
...
Answered By - PSkocik Answer Checked By - Candace Johnson (PHPFixing Volunteer)
0 Comments:
Post a Comment
Note: Only a member of this blog may post a comment.