On Sun, 06 Apr 2008, Massimo Belgrano wrote:
> How Will work #pragma?
> #ifdef __XHARBOUR__
> #PRAGMA DEBUGINFO=Off
> #ENDIF

In both compilers it works in the same way.
xHarbour uses PP borrowed from Harbour code with few small modifications.

> How Will work untraslate
> #ifdef __XHARBOUR__
>   #xuntranslate lj_gotoxy  (   //   =>
>   #xuntranslate LJ_SAY     (   //    =>
>   #xuntranslate LJ_FILL    (   //    =>
>   #xuntranslate LoPrPcx    (   //   =>
> #ENDIF

In the Clipper compatible PP the match pattern depends also on result
pattern. It means that two rules can have literally the same match
pattern but because result pattern is different then they will accept
different expressions. Please look at these two PP commands:

   #command CMD <x> [, <y>] => ? "CMD1:", <x> [; ?? <y>]
   #command CMD <x> [, <y>] => ? "CMD2:", <x>; ?? <y>

Both commands have exactly the same match pattern and only the result
pattern is different. But having the same match pattern they will accept
different line, f.e.:

   #command CMD <x> [, <y>] => ? "CMD0:", <x> [; ?? <y>]
   #command CMD <x> [, <y>] => ? "CMD1:", <x> [; ?? <y>]
   #command CMD <x> [, <y>] => ? "CMD2:", <x>; ?? <y>
   proc main()
   CMD 1          // CMD2:          1
   CMD 1, 2       // CMD2:          1         2
   CMD 1, 2, 3    // CMD1:          1         2         3
   return

As you can see rules with CMD1 and CMD2 are still active.
Rules with CMD0 is hidden by CMD1. Now programmer may want
to disable only rule CMD1 to restore CMD0 functionality.
It can simply make:
   #uncommand CMD <x> [, <y>] => ? "CMD1:", <x> [; ?? <y>]

and now
   CMD 1, 2, 3
shows:
   CMD0:          1         2         3

It means that without passing result pattern rule it's not
possible to well detect which rule should be untranslated.
I implemented such functionality in both compilers but later
in xHarbour it was broken probably due to not sufficient
knowledge about PP internals so now in xHarbour you can
untranslate only the last rule which has the same match
pattern though it can accept different data.
Looks like xHarbour reach the level when it has to be be bug
compatible with older xHarbour releases. Result of bad design
decisions and not well thought features.

>  Is not possible somethink like?
> #ifdef __XHARBOUR__ .OR. ifdef __HARBOUR__ ?

   #IFDEF __HARBOUR__

is accepted by both compilers.

   #IFDEF __XHARBOUR__

is accpeted only by xHarbour.

Both compilers support C like #IF / #ELIF / #ELSE / #ENDIF directive
so you can use:

   #IF defined( __HARBOUR__ ) .AND. !defined( __XHARBOUR__ )
      ...
   #ENDIF

best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to