Hi Przemek,
> > 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.
I'm not so expert in prototyping, thus i could made some incorrect
assertion.
The true problem isn't probably in Harbour, but in Watcom/Harbour
compilation respect to Watcom/xHarbour one.
This is the Watcom/Harbour output:
...
Function Prototype:
HB_FUNC_EXTERN( ANIMATE_CREATE );
HB_FUNC_EXTERN( ANIMATE_OPEN );
HB_FUNC_EXTERN( ANIMATE_PLAY );
HB_FUNC_EXTERN( ANIMATE_SEEK );
HB_FUNC_EXTERN( ANIMATE_STOP );
HB_FUNC_EXTERN( ANIMATE_CLOSE );
...
Function body:
HB_FUNC_STATIC ( ANIMATE_CREATE )
HB_FUNC_STATIC ( ANIMATE_OPEN )
HB_FUNC_STATIC ( ANIMATE_PLAY )
HB_FUNC_STATIC ( ANIMATE_SEEK )
HB_FUNC_STATIC ( ANIMATE_STOP )
HB_FUNC_STATIC ( ANIMATE_CLOSE )
This is the output obtained using Bcc/xHarbour, but Andi Jahja reported this
worked also for Watcom/xHarbour.
HB_INIT_SYMBOLS_BEGIN( hb_vm_SymbolInit_HANIMAT )
........
{ "HANIMATION_NEW", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_NEW )}, &ModuleFakeDyn },
{ "HANIMATION_ACTIVATE", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_ACTIVATE )}, &ModuleFakeDyn },
{ "HANIMATION_INIT", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_INIT )}, &ModuleFakeDyn },
{ "HANIMATION_OPEN", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_OPEN )}, &ModuleFakeDyn },
{ "HANIMATION_PLAY", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_PLAY )}, &ModuleFakeDyn },
{ "HANIMATION_SEEK", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_SEEK )}, &ModuleFakeDyn },
{ "HANIMATION_STOP", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_STOP )}, &ModuleFakeDyn },
{ "HANIMATION_CLOSE", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_CLOSE )}, &ModuleFakeDyn },
{ "HANIMATION_DESTROY", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_DESTROY )}, &ModuleFakeDyn },
.....
Maybe this can better clarify what i was meaning.
> > 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.
If i don't do it, the symbol of C function become external and callable by
other modules of application and not only by the class prg code containing
the method.
Best regards.
Maurizio
> -----Messaggio originale-----
> Da: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Per conto di
> Przemyslaw Czerpak
> Inviato: giovedì 5 giugno 2008 18.56
> A: Harbour Project Main Developer List.
> Oggetto: Re: [Harbour] HB_STATIC_FUNC
>
> 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
>
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
