On Sat, 18 Jul 2009, Phil Krylov wrote:
Hi,
> This code:
> PRIVATE l1, l2, d, s
> REPLACE &L2 WITH d FOR LANGUAGE = L1
> REPLACE &L1 WITH s FOR LANGUAGE = L2
> does not compile with the error message in subject. It compiles and
> works ok in xHarbour. Why? The preprocessed code is the same,
> DBEval( {|| _FIELD->&L2 := d}, {|| LANGUAGE = L1},,,, .F. )
> DBEval( {|| _FIELD->&L1 := s}, {|| LANGUAGE = L2},,,, .F. )
Harbour behavior is exactly the same as Clipper.
Just try to compile this results with Clipper.
BTW you have to use -a compiler switch to reach such effect.
The error message is correct. To understand it please look at this
reduce example of the above problem:
memvar l
local cb
cb := {|| &m->v + l }
Please look at generate code:
HB_P_PUSHSTRSHORT, 12, /* 12 */
'{', '|', '|', '&', 'm', '-', '>', 'v', '+', 'l', '}', 0,
HB_P_MACROTEXT,
HB_P_MACROPUSH, 11,
Though block is declared explicitly then it's passed as string
and macrocompiled at runtime. It means that all variable scope
declaration stop to work. Though we declared l as memvar in our
code then we have nothing to force memvar access in macrocompiled
block. If during evaluation there is field caled 'l' in current
workarea then it will have higher priority then memvar variable.
Please note that user correctly declared variable in the code
and does not expect that declaration can be dropped in hidden
way so it's extremely important to inform him about such situation
at compile time. Otherwise it may cause unexpected behavior
at runtime very hard to locate and debug. Compiler error allows
user to modify the code immediately and add explicit casting,
f.e. in this case it's enough to change codeblock and add
explicit memvar aliasing to l variable: m->
cb := {|| &m->v + m->l }
xHarbour generates error in such code only when l variable is
declared local or static. It does not generate errors for fields
(wrong because they can be aliased by declaration) and memvars.
I can only guess that someone who didn't understand the problem
"optimized" the code. Additionally he made it wrong and does not
check declaration precedence so xHarbour generates error for code
like:
static l
proc main()
memvar l
local cb
cb := {|| &m->v + l }
return
But declaration precedence in xHarbour needs serious cleanup in many
other places too. I.e. GLOBALs were added without any respect to
existing Clipper rules which allows to hide some file wide declarations
by local ones, some declarations can be used in illegal places in the code
or have no effect, etc...
I.e. try this code:
/* compile with -n -w switches and also with -n -w -a and compare results */
static v:="static"
proc main()
public v:="public"
? v, M->v
return
I can understand that xHarbour may refuse to compile this code but if
it tries to make it then such extension has to be implemented correctly.
HTH,
best regards,
Przemek
ps. I looked at some contrib thread support in DJGPP and I was not able
to find any PTHREAD compatible library but I've found two ones:
jtlwp20s.zip and pdmlwp03.zip. The second one is based on the 1-st
one so both uses the same mechanism to task switching which is
done in the interrupt what creates some problems. Because neither
DOS nor DJGPP CRTL is reentrant safe to use such threads is necessary
to encapsulate all CRTL/OS function calls in code which disable task
switching and then enable it when function returns. For such big
projects like Harbour with possible 3-rd party libraries it's very
hard to pass such condition so it will be hard for us to use them.
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
