It will be clear (once you've used function pointers for a while) that
there are times when using function pointers is necessary, and times when
they're not. I think every situation is different, but consider this
SELECT CASE I
You can generalize this situation, for example, a menu with several options, or
perhaps a parser (yes Rapid-Q does use function pointers to parse your code).
As you may notice, that's a lot of comparisons, especially if you're writing
a parser where there's so many keywords (over 50 say).
We can easily eliminate these comparisons by using function pointers,
consequently speeding up your program. See FUNCPTR.BAS for a concrete example.
BIND FPtr(1) AS Process1
BIND FPtr(2) AS Process2
BIND FPtr(3) AS Process3
BIND FPtr(4) AS Process4
BIND FPtr(5) AS Process5
BIND FPtr(6) AS Process6
BIND FPtr(7) AS Process7
x = VAL(INPUT$(1))
None of the code you see above is executable as is, but I think you get the
general idea. We don't need any case statements as you can see (this is assuming
you've partitioned your function pointers properly).
11.4 What is not supported in Rapid-Q
Function pointers as arguments is not supported. As funny as that sounds, this is actually
very useful. Unfortunately I didn't get a chance to implement this (yet).
You can pass the function pointer value as an argument, but as you can see,
you won't be able to call your function. The only way would be to define a
global function pointer as your template, and then assign that to your argument.
It's easier to see with an example:
DECLARE FUNCTION MyFuncTemp (X AS LONG) AS LONG
DECLARE FUNCTION Func1 (X AS LONG) AS LONG
DECLARE FUNCTION Func2 (X AS LONG) AS LONG
DIM Template AS INTEGER
DIM I(100) AS INTEGER
BIND Template TO MyFuncTemp
BIND I(1) TO Func1
BIND I(2) TO Func2
SUB Test (FPtr AS INTEGER)
Template = FPtr
PRINT CALLFUNC(Template, 10)
That's about the only way you can work around this limitation.