Most people here have switched from xharbour to xharbour
Usefull if you want post the Modification required
I have collect same post about it
TDifferences from harbour legend:
HB=Harbour XHB=xHarbour
[HB|XHB] has means the the other hasn't
[HB|XHB]= means different names for a "comparable thing"
> list:
> - XHB=IN HB=$
Not true. XHB can use IN as synonym of $.
IN in xHarbour does not make any other job then $ and is translated by
lexer to $.
$ in xHarbour has additional functionality. It can be used also for
ARRAYs and HASHes.
In Harbour such functionality is enabled by HB_COMPAT_XHB though here I
think that it may be good to enable it by default too.
> - XHB has LIKE
and also HAS. IN, HAS, LIKE are not enabled in Harbour because using
identifiers as operators breaks PP rules. In PP identifiers have
different precedence then non id characters use for operators so they
cannot be added to Harbour without breaking compatibility with Clipper.
> - XHB has HBLOG functions
Just like few other RTL functions but most of them can be collected in
separate library and added to Harbour without any problems.
> - HB has hbcompat.ch ( to help port XHB prgs )
Please note that this file has two sections. It can be usable also in
xHarbour so I suggest to add it also to xHarbour CVS.
> - common.ch is different
nothing seriously important what cannot be hidden by few rules in
hbcompat.ch
> - HB compiler has -kM switch
> - XHB compiler has -J<app>.hil ( and some i18n support )
I'll add i18n support to Harbour though I have some doubts if
reinventing the wheel is good idea. Instead of using our own format I
plan to use gettext format so it will be possible to use a lot of well
known different tools which help in translations and also make lot of
them automatically.
> - pcre lib HB=hbpcre XHB=pcrepos
> ( here I vote for hbpcre )
> - contrib/gd HB=hbgd XHB=gdlib
> ( here I vote for hbgd )
> - XHB gt subsys "requires" gtnul HB doesn't have it
Not true. Harbour have GTNUL and it's always included in RTL library.
> - HB gt subsys has gttrm as default for Linux/Unix XHB doesn't have it
> - XHB has HB_OpenProcess/HB_ProcessValue
The same as for HBLOG above.
> - HB has #pragma escapedstrings = on
> - HB has SET EOL <eol>
> - XHB has some trace functions at prg level like valtoprg, tracelog,
...
The same as for HBLOG above.
> - XHB shell scripts are xhb* HB are hb*
IMHO it's good - you can use both compilers simultaneously on the same
machine.
> P.S. if xHarbour would use -W2 to warn about unused prg's vars in RTL
> it would help to move code from xHarbour to Harbour.
This is my list oriented to core code extensions.
IMHO adding separated functions to the list does not make big sense
because anyone can port most of them between project in few hours.
XHARBOUR core extensions not supported by Harbour even with
HB_COMPAT_XHB
========================================================================
=
1. bit operators: BITAND(&) BITOR(|) BITXOR(^^) BITSHIFTR(>>)
BITSHIFTL(<<) 2. IN, HAS, LIKE operators
Probably I'll add #operator directive to PP so support for them can
be added in hbcompat.ch if someone will need it.
3. using one character length string as numeric value
Probbly will be never supported - at least I do not want to make it.
It causes even more problems then using [] for strings.
4. reverted behavior of item references stored in arrays
Implemented strictly (not like in xHarbour where it's not respected
in some places) will have some good effects eliminating some Clipper
anomalies and in general it's not bad idea. Unfortunately it breaks
Clipper compatibility so I do not think that Harbour will support it
(at least in default build) because users have code which needs
original Clipper behavior. This code was using arrays as workaround
for limited in Clipper number of function parameters.
AFAIK in xHarbour it was reverted only for one reason: when user
assigns item in array returned by hb_aParams() and corresponding
parameter was passed by reference then reference is respected and
original parameter is changed. I do not know any other reasons why
in xHarbour it was changed breaking Clipper compatibility.
5. background tasks
I hope we will add them with Ryszard's asynchronous task library
6. GLOBAL / GLOBAL EXTERNAL (GLOBAL_EXTERN)
I think that I'll add them somewhere in the future but it will
be implemented internally in different way then in xHarbour.
In xHarbour GLOBALs can be used _ONLY_ if compiler generate C
code and the implementation strictly depends on C compiler and
linker behavior.
7. MT mode
Harbour does not have MT mode yet. I'll add it but the low level
implementation will be absolutely different then xHarbour ones.
In fact for real MT mode it's necessary to make much deeper
modifications then in xHarbour. In xHarbour most of subsystem was
never updated for MT mode so xHarbour MT applications can crash
randomly, f.e. classes code is not protected at all and new classes
can be added dynamically. It means that if one thread executes some
methods and other will create new class (1-st time calls class
function) then you have very bad race condition because s_pClasses
will be reallocated and can change its address in memory. For real
MT mode all such problems have to be resolved.
We can also create list of Harbour features not supported by xHarbour.
"abcd"[2] => "b"
is posible in xHarbour but not in Harbour
This syntax is supported only when you compile Harbour with
HB_COMPAT_XHB macro but with working range checking and will not be
enabled in default build to its side effects. For sure I will never
replicate exact xHarbour behavior because it simply disables RT error if
I make some mistake in index of multidimensional arrays, f.e.:
proc main
local s:="ABC"
? s[1,2,3,4,5,6,7,8,9]
return
xHarbour compiles and executes this code without any errors.
In the past when I was using xHarbour for my applications I lost much
more time looking for errors in wrong indexing then I can ever benefit
from the above feature. People writing plagins for my applications also
asked me why they are not working as expected in some cases and it was
caused by typos in array indexing. Now I simply answer: recompile the
code with Harbour and check if all indexes are correct and I do not want
to return to this problem again. For sure no one who has to use often
multidimensional arrays would never introduced such feature.
Enabling range checking like in Harbour compiled with HB_COMPAT_XHB
macro does not resolve the whole problem because cVal[n] returns string
so the above code can be changed to:
proc main
local s:="ABC"
? s[1,1,1,1,1,1,1,1,1]
return
and now also Harbour will not generate RT error. The only one solution
for above problem is changing returning 1 character string value to
numeric value with ASCII code of given character and this is the default
Harbour behavior when compiled without HB_COMPAT_XHB and compile time
(-ks) and runtime (//FLAGS:s) switches are used. In such case:
proc main
local s:="ABC"
? s[2]
return
shows:
66
and:
? s[2,1]
generates RT error.
Massimo Belgrano
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
