Hi Przemek,
In general there is a problem with compile time optimizations for
CHR( <integer_value> * 256 )
and $ operator in expressions like:
"" $ <exp>
caused by bugs in Clipper compiler. It gives different results then
runtime functions/operations. Keeping strict Clipper compatibility
is hard in complex expressions. Probably we should think about adding
option to set valid results in such situations or we should introduce
flag for expressions to mark them as optimized and in such case do
not
replicate wrong Clipper compile time optimizations.
We may guard those with #pragmas for Harbour, to
disable compile time optimization for these cases,
or better yet, add both versions to make the
difference more apparent.
One thing I forgot: To do this we'd need a switch
which would toggle the parenthesised expression
optimization only.
BTW, for me it's unclear by looking at the 'harbour /k?'
help, which options are enabled by default, and what
is the relation between them. It's unclear whether
'-kh' actually means all, or a selection of options
turned on, or something else.
Plus, rather than saying 'lowercase/uppercase significant'
it would be more intuitive to just use lowercase
for 'J' and 'M', and make casing not to matter, like
for the rest of Harbour switches. I can make this, but
I wonder if there was any special reason doing it like
this?
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
