[futurebasic] Re: [FB] Dynamic Functions?

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : July 2008 : Group Archive : Group : All Groups

From: Max Taylor <maxclass@...>
Date: Thu, 17 Jul 2008 22:26:41 -0700
On Jul 17, 2008, at 9:53 PM, Brian Stevens wrote:

>
> On Jul 17, 2008, at 5:36 PM, Max Taylor wrote:
>>
>> What if I wanted to send a 'short' or a 'pointer' or a 'single', or  
>> a 'double' to the above example once it has been DEF'd?
>>
>
> To quote the reference manual: "The number, order, and data types of  
> the
> parameters in the Def Fn Using <Fn address> list must match the  
> number, order, and data
> types in the parameter list of the referenced function"

Yes, I am fully aware of the above and how they MUST match the  
definition.

> Good try but Def FN  using is not the answer for what you seek( but  
> keep reading ).

I use DEF FN because I only call FN's by address and NOT by name. I  
have not been able to find another way to invoke a FN using its  
address in FB. Hence the original question.

>> Could the number and type of the parameters be totally dynamic?
>>
>> Is it possible to build such a FN?
>
> The question's timing is good. Recently, the FBtoC team ( mostly  
> Bernie ) pondered how to use a Core Foundation call that accepts a  
> variable number of parameters ( CFStringCreateWithFormat ) without  
> interfering with the possible use of the same call by the FBer's  
> code. A PASSTHROUGH solution is possible but ugly. Bernie did some  
> research and came up with the va_start and va_list C macros. The  
> work is still in progress ( and experimental ---so no promises )   
> and hasn't been submitted to the team yet, but initial work is  
> promising. So, yes there is a possibility that calling user FNs with  
> multiple parms is possible. However, when/if implemented it will be  
> FBtoC-only.

Thanks for the above paragraph. It is interesting to see how others  
may solve a closely related problem.

It seems to me that in a computer where parameters are either placed  
on some sort of stack or in a processors registers that in either case  
the processor or the stack is unaware of the data type. It appears  
that when pulled from the stack or manipulated within a register the  
data are expected to match the type that is being looked for. I might  
be wrong, but I have never known a register to be of type pointer, or  
handle, or short or long, etc. but if one places a pointer in a  
register or on a stack then it is expected that a pointer is what is  
assumed or a pointer is expected to be pulled from the stack.

If any of the above it true then it seems possible that almost any  
data type can be pushed onto some (custom?) stack at one place, a FN  
called and the information on the stack retrieved by the called FN in  
the proper order like I assume a normal FN does when called. All this  
with no more overhead than if the information were passed within the  
FN call and the FN pulls it from some system stack.

As long as the information in the list (on the stack) is placed and  
retrieved in the proper order who should care how it got there. Maybe  
I am missing something here but when my dual-core processor is running  
at 3.06 GHz it does not seem to me that performance would be much or  
an issue here.

Maybe I should try creating my own stack, putting the values thereon,  
calling a FN by its address and then retrieving the parameters from my  
custom stack that are required for that particular FN.

Just some thoughts to sleep on.

Anyway it's bedtime so good night for now. Maybe the answer will come  
in a dream (yea, right).


Max Taylor
The MaxClass Guy