In xHarbour the behavior of references stored in array is reverted in
comparison to Clipper or Harbour.
In Clipper and Harbour VM executing code like:
aVal[ 1 ] := 100
clears unconditionally 1-st item in aVal array and assigns to it value 100.
xHarbour checks if aVal[ 1 ] is an reference and in such case it resolves
the reference and then assign 100 to the destination item.
On access Clipper and Harbour VM executing code like:
x := aVal[ 1 ]
copy to x the exact value stored in aVal[ 1 ]. xHarbour checks is aVal[ 1 ]
is an reference and in such case it resolves the reference and then copy to x
the value of reference destination item.
It can be seen in code like:
proc main
local p1 := "A", p2 := "B", p3 := "C"
? p1, p2, p3
p( { @p1, p2, @p3 } )
? p1, p2, p3
proc p( aParams )
local x1, x2, x3
x1 := aParams[ 1 ]
x2 := aParams[ 2 ]
x3 := aParams[ 3 ]
x1 := lower( x1 ) + "1"
x2 := lower( x2 ) + "2"
x3 := lower( x3 ) + "3"
Harbour and Clipper shows:
A B C
a1 B c3
but xHarbour:
A B C
A B C
It's not Clipper compatible so in some cases it may cause portability
problems. F.e. code like above was used in Clipper as workaround for
limited number of parameters (32 in Clipper). But it allows to directly
assign items of arrays returned by hb_aParams() and updating corresponding
variables passed by references (see functions with variable number of
parameters below).
Anyhow the fact that xHarbour does not have '...' operator which can
respect existing references in passed parameters and does not support
named parameters in functions with variable number of parameters causes
that reverted references introduce limitation, f.e. it's not possible
to make code like:
func f( ... )
local aParams := hb_aParams()
if len( aParams ) == 1
return f1( aParams[ 1 ] )
elseif len( aParams ) == 2
return f2( aParams[ 1 ], aParams[ 2 ] )
elseif len( aParams ) >= 3
return f3( aParams[ 1 ], aParams[ 2 ], aParams[ 3 ] )
endif
return 0
which will respect references in parameters passed to f() function.
No comments:
Post a Comment