简体   繁体   中英

C pointer notation compared to array notation: When passing to function

My question is base on the following code:

int myfunct(int ary[], int arysize)   
int myfunct2(int *ary, int arysize)

 int main(void){
   int numary[10];
   myfunct(numary, 10)
   myfunct2(numary, 10)
   return;
 }

int myfunct(int ary[], int arysize) {   
      //Whatever work is done

  }

int myfunct2(int *ary, int arysize) {
     // Whatever work is done

  }

Is there a reason to use one of these over the other? To elaborate, when concerned with numeric arrays, is there any reason one would want to use pointer notation over array notation. If one uses pointer notation then within the function pointer arithmetic would be used etc.. AND if one uses the [] array notation, one could work with the array as usual. I'm new to programming and I currently do not see any benefit to using the pointer notation.

My precise question, is there any reason to pass a numeric array to a function using pointer notation and therefore using pointer manipulations within the function.

When you declare a function parameter as an array, the compiler automatically ignores the array size (if any) and converts it to a pointer. That is, this declaration:

int foo(char p[123]);

is 100% equivalent to:

int foo(char *p);

In fact, this isn't about notation but about the actual type:

typedef char array_t[42];
int foo(array_t p);  // still the same function

This has nothing to do with how you access p within the function. Furthermore, the [] operator is not "array notation". [] is a pointer operator:

a[b]

is 100% equivalent to:

*(a + b)

There is no real functional difference between the two notations. In C, when you pass an array variable to a function, it decays to a pointer regardless of the notation. However, in my opinion, the pointer notation is preferable . The problem with [] notation in function definitions is that, in my opinion, it is somewhat misleading:

void foo(int array[])
{

}

A ubiquitous mistake among novice C programmers is to assume that sizeof(array) will give you the number of elements in the array multiplied by sizeof(int) , like it would if array were an array variable declared on the stack. But the reality is that array has been decayed to a pointer, despite the misleading [] notation, and so sizeof(array) is going to be sizeof(int*) . array is really just a pointer to the first element, or possibly a pointer to a single integer allocated anywhere.

For example, we could call foo like this:

int x = 10;
foo(&x);

In which case the [] notation in the definition of foo is kind of misleading.

Those declarations are absolutely identical. To quote the standard:

A declaration of a parameter as "array of type" shall be adjusted to "qualified pointer to type"

C99 standard section 6.7.5.3 paragraph 7

In modern C that has variable length arrays since C99, the array notation is preferable if is an array , I think. For one dimensional arrays, you can do things like

int myfunct(size_t size, int array[size]) {
  ... array[i] ..
}

and for two dimensional

int myfunct(size_t size, int array[size][size]) {
  ... array[i][j] ..
}

So array notation fits much better in the general picture. A sophisticated compiler could then even do bounds checking, but I don't know of any that does this yet.

In my opinion, the main reason to prefer pointer notation over empty array notation in function prototypes is that the latter is not consistent with structure definitions:

struct person {
   char *firstname;
   char *lastname;
};

void setperson(struct person *p, char firstname[], char lastname[])
{
    p->firstname = firstname;
    p->lastname = lastname;
}

In structures you will have to use the pointer notation anyway because empty array notation is only valid, at least since C99, for the last member when you want to make it a flexible array member .

You only need to use the array notation for multidimensional arrays. (You do not have to provide the size of the first dimension).

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM