array of function pointers

**MK27** · 09-15-2009

Use the TYPEDEF!

**tabstop** · 09-15-2009

Did you ever get the declaration of your array fixed?

**itCbitC** · 09-15-2009

Originally Posted by kiros88

Code:

int status = (FIPFunc[(Uint32) hdr->Code] [(Uint32) hdr->Subcode])(DescListPtr, DescListLen);

So i put that with the brackets in the right order but i still keep getting the error
error: called object ‘FIPFunc[(unsigned int)hdr->Code][(unsigned int)hdr->Subcode]’ is not a function
which its not a function cuz Its suppose to be an array?

So what does this really mean? You are trying to create a 2D array and also an array of pointers to functions that return an integer. You can do either one or the other but not both.

Code:

int status = (*FIPFunc)(arg1, arg2);   /* FIPFunc is a pointer to a function that takes 2 arguments and returns an int */
int (*FIPFunc[10]) (arg1, arg2);       /* this is an array of pointers to functions that take 2 arguments and return an int */

**kiros88** · 09-15-2009

Originally Posted by MK27

Use the TYPEDEF!

Sorry bout that didn't understand until i read more on it but i tried

Code:

typedef void(*FIPF)(Uint8,Uint32);
int status = (FIPFunc[(Uint32) hdr->Code] [(Uint32) hdr->Subcode])(DescListPtr, DescListLen);

And theres no such luck im not sure how to typedef it since its 2-D

And I did get declaring it to work since i used a
void* FIPFunc.......
and the void* allowed it to compile ......

**MK27** · 09-15-2009

Originally Posted by kiros88

And theres no such luck im not sure how to typedef it since its 2-D

No no no no no! You typedef the (singular) function ptr prototype you want to use, and then you can create any kind of array you want with it:

Code:

typedef (*FPtr)(int);
FPtr fray[10][10];
fray[0][0]=myfunc;
fray[0][1]=someotherfunc;
...etc.

Nice, tidy, simple.

**kiros88** · 09-15-2009

Code:

typedef (*FIPF)(int);
FIPF FIPFunc[4][2];

void FIPinit(){
  FIPFunc[0][0] = &FIPDiscSolicit;
}

int FIPDiscSolicit(Uint8 *DescListPtr, Uint32 DescListLen)
{
}

I tried this out but i get this warning
fip.c:19: warning: assignment from incompatible pointer type
The warning is in the FIPInit() but iono whats wrong wit the pointer type

O yea and I'm having a problem calling it now
int status = (FIPFunc[(Uint32) hdr->Code] [(Uint32) hdr->Subcode])(DescListPtr, DescListLen);
I get
too many arguments to function ‘FIPFunc[(unsigned int)hdr->Code][(unsigned int)hdr->Subcode]’

UHH YES IT COMPILED iono if really works but at least it compiled im going to test it around now see if its all okay

**quzah** · 09-15-2009

Why are you using the address-of operator?

Quzah.

**tabstop** · 09-15-2009

So why not do the typedef to match what it's supposed to be?

Code:

typedef int (*FIPF)(Uint8 *, Uint32);

(Edit: And if you haven't prototyped the function, the compiler won't know that it's a function either....)

**C_ntua** · 09-15-2009

Out of curiosity, why do you want a 2D array of function pointers? What are you trying to do here?

**MK27** · 09-15-2009

Originally Posted by quzah

Why are you using the address-of operator?
Quzah.

Ditto. kiros88, I gave you an example: do you see & there? You have to pay attention to details or they will just bury you.

Also, the prototypes need to match, look:

Code:

typedef (*FIPF)(int);  /* this function has one arg, an int */
int FIPDiscSolicit(Uint8 *DescListPtr, Uint32 DescListLen) /* this function has two args, niether of them int */

BTW, for a non int function you need to include the type:

Code:

typedef char *(*FPtr)(int);

returns char *ptr.

**cas** · 09-15-2009

BTW, for a non int function you need to include the type:

I see no reason why you would ever leave the type off (especially since implicit int disappeared in C99).

Also, as a more general question, what's the problem with using the address-of operator on a function? I don't do it myself, but there's nothing wrong with it. It makes some sense to use it, I think, to make it obvious what the code is doing. It's somewhat akin to using &array[0] instead of array; both work just fine and mean the same thing (again, in most contexts). Unless I'm missing something obvious here, of course.

**C_ntua** · 09-15-2009

Yeah,
a and &a[0] are the same, but are not the same with &a, which I believe was the error here

**cas** · 09-15-2009

Originally Posted by C_ntua

Yeah,
a and &a[0] are the same, but are not the same with &a, which I believe was the error here

But that's the case for an array, not a function. &func and func are the same thing (except in a couple of corner cases).

**quzah** · 09-15-2009

Originally Posted by cas

But that's the case for an array, not a function. &func and func are the same thing (except in a couple of corner cases).

C: A Reference Manual, 5th ed, page 208:
The name of a function evaluates to that function; it is not an lvalue. Unless the function name is the argument of the address operator (&) or the argument to sizeof, the name is converted to a pointer to the function as part of the usual unary conversions. The result of &f is a pointer to f, not a pointer to a pointer to f, and sizeof(f) is invalid.

[edit]
In case anyone cares...

C: A Reference Manual, 5th ed, page 167:
An expression of type "function returning..." that is not used in a function call, as the argument of the address operator, &, or as the argument of the sizeob operator is immediately converted to the type "pointer to function returning...." (Not performing the conversion when the function is the argument of sizeof ensures that the sizeof expression will be invalid and not just result in the size of a pointer.) The ony expressions that can yield a value type of "function returning T" are the name of such a function and an indirection expression consisting of the unary indirection operator, *, applied to an expression of type "pointer to function returning...."

Example
The following program assigns the same pointer value to fp1 and fp2:

extern int f();
int (*fp1)(), (*fp2)();
fp1 = f; /* implicit conversion to pointer */
fp2 = &f; /* explicit manufacture of a pointer */
[/edit]

Quzah.

**cas** · 09-15-2009

Right. When I say corner cases I mean you can't apply & to &func (which is pretty obvious), and you can't apply sizeof to func (which is less obvious). In other cases, it's treated as a pointer to the function. So when you're passing a function (pointer) to another function, or assigning it to a function pointer variable, and so on, you can either use the & or not. Both are valid.