Hi Przemek,
What is IMHO wrong. In such case you have situation like the one
you wanted to avoid but it happens only in Clipper not in Harbour.
In summary current Harbour behavior for me is much more cleaner.
Let's take this simple code:
--
FUNC Main()
<ASCII- 20>QOut( "0" )<CRLF>
<ASCII-160>QOut( "1" )<CRLF>
<ASCII- 20>QOut( "2" )<CRLF>
--
'harbour /n' output:
Lines 3, Functions/Procedures 1
... Done.
'clipper /n' output:
...prg(3) Error C2004 Illegal character: '...'
1 error
No code generated
If I replace ASCII-160 with a zero byte, Harbour
_will_ report an illegal char (but Clipper won't, which
is wrong).
So, what I fail to see is what this issue have to
do with preprocessor. There is nothing in the source
which would involve any PP logic, so I would think
it's passed to the compiler. Now the compiler finds
such a character which cannot be used in normal code,
and for byte zero it reports an error, for byte 160,
it reports nothing, and silently won't generate _any_
code after processing line 2. This is not right IMO,
users should be at least warned that their source code
is not getting compiled for whatever reason. (it also
reports 3 processed line, while in reality only
one was processed and compiled.)
The other question is if Harbour can report an illegal
char for zero byte, why can't it report one for
ASCII-160? Both are illegal in that context.
To make it even more interesting ASCII-1 will generated
both an illegal char and a syntax error in Harbour
(and only illegal char in Clipper).
[ I agree that for your examples Harbour is rightly
generating an error.]
Brgds,
Viktor
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
