Argthtjtr

I was trying to understand function pointers in C. While reading about it on internet (mostly stack overflow QAs) - I came across 2 ways in which I can assign value to a function pointer

#include <stdio.h>



double add(int a, double b) {

  return a + b;

}



double subtract(int a, double b) {

  return a - b;

}



int main() {

  int op_a = 23;

  double op_b = 2.9;



  // Case 1. Just pass the function (not its address)

  double (*math_op)(int a, double b) = add;

  printf("The output of Math Operation %fn", math_op(op_a, op_b));



  // Case 2. Pass the function's address

  math_op = &subtract;

  printf("The output of Math Operation %fn", math_op(op_a, op_b));



  printf("End of programn");

  return 0;

}

I have couple of questions

1. In the code above - what is the right way to assign value value to function pointer. I see several answers on stack overflow which follow the convention followed in case 1, and I also see some answers following convention in case 2. Both seem to be working correctly for me. Which is one is correct (or preferable)?


2. Also, in order to call function pointers I see 2 ways in which you can call them - math_op(op_a, op_b) or (*math_op)(op_a, op_b). Again, is there a preferable way of doing this - both seem to be working correctly for me.

I think

Function calls (§6.5.2.2/1):

The expression that denotes the called function shall have type pointer to function returning void or returning an object type other than an array type.

is enough to answer both of your questions. The name of a function is implicitly converted to pointer to function type so using the address-of operator when assigning the adress of a function to a function pointer is superfluous. As for calling functions by function pointers the syntax is no different from "ordinary" function calls.

This is really a quirk of C. The * and (a single) & are kind of ignored when taking an address of a function.

int main() {

    printf("%p %p %p", (void*)add, (void*)************add, (void*)&add);

}

The * are ignored when "dereferencing" a function pointer

int main() { 

    double (*math_op)(int a, double b) = add;

     printf("%p %p %f", (void*)math_op, (void*)*************math_op, (***************math_op)(1, 1.0));

}

It does not matter. However be consistent. Mostly I saw no * nor & used in such contexts.

Case 1 is preferred.

The & is optional to take the address of a function (just like: char buf[100]; char *bp = buf;)

The reason case 1 is preferred is that the syntax is the same for assignment to a function pointer from a function address or another function pointer:

typedef double (*math_func)(int a, double b);

math_func math_op = add;

math_func math_op2 = sub;

math_func math_op3 = math_op2;

Analogously, that's why you can say: math_op(2,23) as a shorthand for: (*math_op)(2,23)

UPDATE:

Pointer typedefs are not preferred (by me anyway)

They certainly help for function pointers [which Jonathan Leffler makes an exception for].

If you had (e.g.) 10 functions that needed to take an argument that was a function pointer, would you want to spell it out in all 10 function prototypes, particularly if the function pointer took 8 arguments itself?

Suppose [in some API] you had a function pointer:

typedef void (*funcptr)(int x,int y,int z);

Consider that you had functions of the form:

void func(funcptr f,...);

And, you had a call chain of these functions:

a -> b -> c -> d -> apiabc

Functions a-d do not call f--only apiabc does. Only apiabc has knowledge of how to call f properly. The others are merely passing along the opaque [to them] pointer so that apiabc can act on it.

If funcptr ever had to change, changing a-d would be problematic (i.e. they are not part of the API--merely users of it).

On pointer typedefs in general, IMO, they are fine if they are reasonably obvious and consistent.

This would be an example of usages:

typedef struct node *Node;              // poor

typedef struct node *pNode;             // MS (common but, IMO, poor)

typedef struct node *nodeP;             // okay

typedef struct node *nodeptr;           // better?

typedef const struct node *nodecptr;    // better?

IMO, the MS version is poor because if we sorted all names pNode would get intermixed with all [unrelated] pWhatever and not gravitate to node whereas looking left to right nodeP has the dominant part first (i.e. it's related to a node).

IMO, it is hubris for POSIX to lay claim to whatever_t as its province for type names. But, it's low probability that there will be a collision [for me, anyway, because I always use names that are likely to not conflict]. If there is a collision based on a future POSIX type, I lose, and have to change my definitions.

Thus, my personal conventions are:

typedef struct node node_t;

typedef node_t *node_p;

typedef const node_t *node_pc;

Any such convention can be used so long as it's applied consistently. In a given set of code, if one encounters foo_p for the first time, yes, one has to look in the .h file for the definition. After that, when one sees bar_p, the convention is already known.

For me, this usually isn't a problem, because when I encounter an unfamiliar code base, I always look at the definitions in the .h file before looking at code in a .c