Hallo, can somebody tell me the difference between
line 1,2,3,4 and A,B. It works all, but what is the better way?

uniqstr:="temp"

sort to (uniqstr) on NAME for !empty(NAME)                 1
sort to (uniqstr) on NAME for !empty(field->NAME)       2
sort to &uniqstr on NAME for !empty(NAME)                 3
sort to &uniqstr on NAME for !empty(field->NAME)       4

use (uniqstr)            A
use &uniqstr           B

Thank you.

Hi Peter,

>uniqstr:="temp"
>//
>sort to (uniqstr) on NAME for !empty(NAME)                 1
>sort to (uniqstr) on NAME for !empty(field->NAME)       2
>sort to &uniqstr on NAME for !empty(NAME)                 3
>sort to &uniqstr on NAME for !empty(field->NAME)       4
>//
>use (uniqstr)            A
>use &uniqstr           B

use option 2 and option A
why? You might ask. let me explain. 
option 1 and uses a NAME, witch can be virtually anything,
(local,private,static,....) while aliasing it with a field-> it makes
sure it uses the field.

the other thing is using macro's. this should be avoided as much as
possible, because it uses way more processing power. while using ( var
) is a simple 'pass-thru for a variable. much cleaner.

regards
Sander Elias

Regards
Sander Elias

Peter,

I agree with Sanders answer of 2 and A with the following additions:

The /v flag of the compiler will affect a non-aliased field reference. 
However, the #command SORT may be adding a field-> reference during 
preprocesing to avoid this problem.  Either way, it is better code to be 
explicit rather than rely on assumptions that could change.

The macro usage also can have evaluation time binding issues related to what 
value the variable has at the time it is referenced depending upon when it 
is referenced.  If the macro resolves to a codeblock and the codeblock is 
retained by the command for later execution, changes to uniqstr after the 
command can affect the result of the codeblock.  Interestingly, in your 
specific case the result is exactly the same on the macro vs non-macro 
portion (see the preprocessor output).

Rodd

"Sander Elias" <Sander@eso.nl> wrote in message 
news:hb0ak117bos5ibg8u56qaphch4djl7peke@4ax.com...
> Hi Peter,
>
>>uniqstr:="temp"
>>//
>>sort to (uniqstr) on NAME for !empty(NAME)                 1
>>sort to (uniqstr) on NAME for !empty(field->NAME)       2
>>sort to &uniqstr on NAME for !empty(NAME)                 3
>>sort to &uniqstr on NAME for !empty(field->NAME)       4
>>//
>>use (uniqstr)            A
>>use &uniqstr           B
>
> use option 2 and option A
> why? You might ask. let me explain.
> option 1 and uses a NAME, witch can be virtually anything,
> (local,private,static,....) while aliasing it with a field-> it makes
> sure it uses the field.
>
> the other thing is using macro's. this should be avoided as much as
> possible, because it uses way more processing power. while using ( var
> ) is a simple 'pass-thru for a variable. much cleaner.
>
> regards
> Sander Elias
>
> Regards
> Sander Elias

Thank you for the answers und for explaining.

That was also my opinion, now I am shure.


"Peter" <peter-baumann-nmb@web.de> schrieb im Newsbeitrag
news:KQwHJ6lyFHA.5608@S15147418...
> Hallo, can somebody tell me the difference between
> line 1,2,3,4 and A,B. It works all, but what is the better way?
>
> uniqstr:="temp"
> 
> sort to (uniqstr) on NAME for !empty(NAME)                 1
> sort to (uniqstr) on NAME for !empty(field->NAME)       2
> sort to &uniqstr on NAME for !empty(NAME)                 3
> sort to &uniqstr on NAME for !empty(field->NAME)       4
> 
> use (uniqstr)            A
> use &uniqstr           B
>
> Thank you.
>
>