Hi,
On Sat, Jul 18, 2009 at 2:23 PM, Przemyslaw Czerpak<dru...@acn.waw.pl> wrote:
> 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 }
Thanks, now I understand. At first it seemed strange to me that
something fixed just by MEMVAR-> aliasing is an error instead of a
warning.
> 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.
Actually what I meant was:
ftp://ftp.chg.ru/pub/pc/djgpp/beta/v2gnu/pth207b.zip
However, I also don't know how they deal with non-thread-safeness of CRT/DOS.
-- Ph.
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
