Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
LEN() function - ugly implementation or bug?
Message
De
26/12/2003 10:22:45
 
 
À
26/12/2003 09:46:44
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
00862121
Message ID:
00862133
Vues:
12
Hi Gregory,

It is true.

But it does not justify the result.
VFP is not multithread virtual machine, and therefore every operation is intrinsically atomic regarding the process, but the application of the parameters is not atomic
( it is only a left to right application ).
CLEAR

x=1

? max(incvalue(@m.x),m.x)

x=1
? max(m.x,incvalue(@m.x))

PROCEDURE incvalue(v)
  v = m.v +1
  RETURN m.v-1
endproc
Therefore the ambiguity between passage for value or reference is not important in one called to one native function.

But i cannot write NATIVEVFP(@m.MyVariable) ( this is the best solution ).

Then, VFP VM must choice to pass the parameters by value or by reference.

Example:
? LEN(m.string)    && use by reference
? LEN((m.string))  && compute a expression
But try this:
memString = SPACE(10000000)
t1=SECONDS()
FOR j=1 TO 100
 	strLenght = LEN(m.memString+SPACE(2384))
NEXT
? TRANSFORM(100/(SECONDS()-m.t1),'@R string lengh = 1000000 999,999,999,999 vfops/s')

t1=SECONDS()
FOR j=1 TO 100
 	strLenght = LEN(m.memString+SPACE(2385))
NEXT
? TRANSFORM(100/(SECONDS()-m.t1),'@R string lengh = 1000000 999,999,999,999 vfops/s')
On my machine the second require double time !!!

Then, probably VFP uses a buffer lightly larger, hoping than to be able to contain the passed parameter, but if the forecast is wrong, VFP copy the parameter an other time!

Fabio
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform