On Thu, 05 Jun 2008, Maurizio la Cecilia wrote:
Hi Maurizio,
> As posted on the hwGUI developers list on 13/04/2008 by Andi Jahja, ther'is
> a different implementation of static funcs at c level of harbour and
> xharbour.
It's not true.
> In harbour a similar declaration results in a HB_FUNC_EXTERN function with
> FS_PUBLIC scope and not in HB_FUNC_STATIC with FS_LOCAL scope.
Again it's not true.
> Maybe the current rearrangement of code in view of a new stable release
> could be a good time for analyzing this problem.
There is no problem in Harbour at all.
The only one problem is in xHarbour which tries to analyze code
inside:
#pragma begindump
<code>
#pragma enddump
guessing it's valid C code to detect function declaration used inside.
And of course it cannot work correctly without adding to xHarbour core
code full functional C preprocessor plus code which will also parse all
include .h files to make this C preprocessor working. This xHarbour
feature have never worked so far for all valid C code and I do not see
any way that it will ever be without investing time to write preprocessor
which will be C compatible and adding to compilation process yet another
pass which will preprocess .c file generated by Harbour with all included
files (also with internal C compiler headers) to detect final compilation
stream. Of course this C preprocessor should have all predefined values
used later by C compiler and also respect local extenssions used by different
C compilers so in practice it will have to be tuned for each compiler we
are using. Do you believe it will be ever finished in xHarbour? I don't.
Just check in generated .c files how xHarbour declares FUNC2() for
code like:
proc main()
? func1()
? func2()
return
#pragma begindump
#include "hbapi.h"
HB_FUNC( FUNC1 ) { hb_retc( "func1" ); }
#if defined(_LOCAL_FUNC2_) && ( __GCC__ - 0 ) >= 0x500
HB_FUNC_STATIC( FUNC2 ) { hb_retc( "static func2" ); }
else
HB_FUNC( FUNC2 ) { hb_retc( "func2" ); }
#endif
#pragma enddump
And this is very trivial example. You can easy imagine much more
complicated.
In the past I proposed that if using #pragma begindump / #pragma enddump
is such very important thing and compiler have to know about functions
declared inside forign code then we should add to .prg code special
declaration for such functions instead of digging in dumped code
(what as I said in pratice cannot be ever well done), f.e.:
DECLARE [STATIC] FUNCTION <FUNCNAME>[(<FUNCPARAMS,...>)]
or:
PROTOTYPE [STATIC] FUNCTION <FUNCNAME>[(<FUNCPARAMS,...>)]
This way also resolves the problem with parameters validation
and prototyping for strong type checking so in the future we
will have support for sth like above for normal .prg code.
As a side effect it may resolve also this problem.
> In hwGUI development some weird coding is needed in mantaining source
> compatibility with either compilers.
For this problem the solution is very easy. Do not use:
#pragma begindump
<code>
#pragma enddump
in .prg code.
In general it's very good practice because without above and
hb_inline() { ... } the HWGUI code will be ready for direct
.obj file generation without C compiler when we will add it
to Harbour.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
