Okay, I admit that this may be useful when trying to interoperate with
another language. But if your program is written in C (and only C),
there's no reason not to just go with
void (*apply)(void (*fn)(void *), void *);
instead.
well, there is a downside:
a function pointer like the above is fixed-form, meaning one is limited
to calling functions where the argument list is known at compile time.
granted, yes, this situation is more rare in the pure C case.
in other cases, people have resorted to large switch statements encoding
"every possible reasonable" set of arguments, but this is bulky and
awkward, and usually has arbitrary limitations (restricting argument
types or number, ...).
granted, the raw function pointer is much cheaper though, as often the
logic for, say, repacking the args list (according to a signature string
or similar), copying the args to where they need to go (on stack or in
registers), and calling the function, is not exactly free (as opposed to
costing, say, 5ns or 10ns, it then costs 50ns or 100ns...).
if one adds the cost of reading arguments from a varargs function, doing
a vtable lookup, ... a method call (via a generic API function, say in
an OO library), can easily take 200ns-300ns or more...
though some cycles can be shaved via generating (and caching) machine
code internally to handle parts of the operation (or "transfer thunks"
as I have called them before, although some added cost remains).
directly calling a method via a function pointer is much cheaper, but
can be a little more awkward (and has annoying edge cases).
so, it is tradeoffs...
often in cases where one needs generic apply and call operations, their
usefulness exceeds their cost.
much like with dynamic types:
a static type is much cheaper and covers the majority of use cases;
however, there are times when a dynamic type is rather useful.
so, support for dynamic types is worth having around, even if most of
the time one may end up not using them.
or such...
