在优化方面，定义带参数和不带参数的函数指针有什么区别

Question

I know that defining function pointer in this way

struct handler_index {
    const char *name;
   int (*handler)();
};

allow to use handler pointer for any function with unspecified (but non-variable) number and types of parameters.

but I m wondering if this definition could affect the optimization of code or memory or execution time comparing to this:

struct handler_index {
    const char *name;
    int (*handler)(int a, int b);
};

Answer 1

If you're wondering how adding more parameters to a function pointer affects specifically the function pointer -- it doesn't. Function pointers are all the same size regardless of the number of parameters.

If you're wondering about efficiency of calling such a function pointer: adding more parameters will result in code being generated to pass arguments. So yea, it will affect code size of the call slightly, and maybe execution time depending on how much ILP your CPU can pull off while passing those args.

Modern calling conventions often pass some number of arguments in registers, so you may or may not have an increase in stack usage.

To see exactly what the difference is between code generated for each call, read up on calling conventions (there are too many to list here!) and check the asm generated from your code. But really, adding more parameters (within reason) is probably going to have such a vanishingly small effect that it simply doesn't matter.

Answer 2

As Cory says, it's not really relevant whether it is a function pointer or just a regular basic function [except in cases where a regular function gets inlined, which of course, function pointers generally can't - although if the situation is specific enough I have seen the compiler actually figure out "Ah, we're always calling function X here, so lets inline X" - typically when the function pointer is an argument to a function, rather than say in a structure).

What WILL make a difference is adding arguments to function calls in general. The processor will have to place those arguments somewhere, and even if they go in registers, it may require extra instructions to get the value into the RIGHT register.

However, your first example is very bad because there's no check that your code is doing the right thing.

Further, you need some pretty pathological cases to make the overhead of passing arguments to a function to be much of the time of calling a function pointer - hopefully your function does more than add one number to another.

Having said that, passing LOTS of arguments, especially "hard to get" arguments can be really bad. I was working on a graphics chip simulator, and part of the pixelshader processing unit had a debug print in the middle of it, which rarely got printed, but it took something like 7 or 8 arguments (aside from the debug level of 1000 or whatever it was). Fishing out those arguments from the respective structures and sticking them on the stack took quite some time, and putting an "if (debuglevel >= 1000) ..." so that the call was only made when it was actually needed, made the code some 40% faster in that function.