I'm not exactly sure I understand. I've always understood that FB can pass
by value or address.
FN callByValue(thisValue,thatValue)
FN callbyAddress(@thisValue,@thatValue)
In FB either the caller or the called function can determine how variables
are passed.
local fn receiveByValue(incomVal1,incomVal2)
end fn
local fn receiveByAddress(@incomVal1,@incomVal2)
end fn
unless the caller is already passing by address I think its pretty clear the
passing method.
Is larry suggesting a way to force a ram variable in the callees paramater
list?
I may have missed some critical point but I dont think so.
W.
-----Original Message-----
From: Robert Purves [mailto:robert.purves@...]
Sent: Tuesday, April 24, 2001 1:34 AM
To: futurebasic@...
Subject: Re: [FB] Re: ~Vars as parameters
>I was proposing that ~ serve to designate a FN variable to be a
>Pascal Var. There are a few VARs in FB already. For example,
>INC(X%) changes X%, so X% is a VAR in INC().
> > Before we get into it, I need a clear example of what
> > you are doing that can't be accomplished under the
> > current structures. I am missing the boat somewhere.
>
>Yes, the issue is *not at all* what can be done but rather how
>fast and smoothly and simply things can be done.
A parameter can be passed to a FN or function or procedure _either_ by
value (the only method supported by FB), _or_ by address (the only method
that was supported by QB). In the latter case only, changes in the
parameter get transmitted back to the caller.
Pascal and C allow parameters to be specified in either way.
The usefulness of Pass-By-Address is evident in tbis quandary:
// How can I return two values from this FN?
local fn SumAndDiff( a#, b# )
dim sum#, diff#
sum = a + b
diff = a - b
end fn
Larry's proposal would allow an elegant solution:
local fn SumAndDiff( a#, b#, ~sum#, ~diff# )
sum = a + b
diff = a - b
end fn
dim @ s#, d# // must be RAM variables for Pass-By-Address
fn SumAndDiff( 4.0, 3.0, ~s, ~d )
print s, d '<--- would print 7 1
Robert P.
--
To unsubscribe, send ANY message to <futurebasic-unsubscribe@...>