>>>
>>>Ok, I got it! But why not simply:
>>>
>>>bitand(lnRight, 0x7f)*256 + lnLeft
>>>
>>>Vlad
>>
>>Traditionally, a low level bitshift is Much faster than multiplication by a floating point value. But since this is foxpro, and we are actualling calling functions, the performance gains are probably lost. The readability is also reduced using my technique whereas in C++ it would be:
>>
>>unsigned char lcShort[2];
>>short x;
>>// ...
>>x = ((lcShort[1] & 0x7f) << 8) | lcShort[0]);
>>x = (lcShort[1] & 0x80) ? (-x) : (x);
>>which would be thousands of times faster than the equivalent FoxPro and tens of times faster than the equivalent C++ using multiplies instead of bit operations.
>>
>>Of course in C++, the initial reason we had to unpack a short becomes moot :-)
>>
>>Peter
>
>Peter & Vlad,
>
>I assumed that using BITOR() would be faster than addition, however, when I ran a series of tests the opposite turned out to be true. The only reason that made any sense to me would be that the mathematical operations are handled by the internal math coprocessor, while this type of operation would be handled by the main. While I haven't tested shift (VFP's) vs. multiplication, it wouldn't surprise me in the least if the same doesn't apply.
>
>George

Actually my theory is that the bitor/bitrshift is in effect calling a function whereas the addition/multiply is more highly optimized in the interpreter.

Peter