t: R: R: R: [Harbour] HB_STATIC_FUNC
Hi Massimo,
> What do you think about using a robodoc for extract from source
> Also here you see that separing prg and c will be more useful for
> generating documentation
I don't know this tools. I'll take a look. Also Francesco was inte
Can this help maurizio with ANIMATE class in hwgui?
-Original Message-
>I used to use (but not very strictly) this method, f.e.:
>w32_reg.prg
>w32_regc.c
>
>Brgds,
>Viktor
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour
Hi Massimo,
> What do you think about using a robodoc for extract from source
> Also here you see that separing prg and c will be more useful for
> generating documentation
I don't know this tools. I'll take a look. Also Francesco was interested to
similar solution in aiding on documentation work
A documentation is important also without documenting HB_STATIC_FUNC
for
now
What do you think about using a robodoc for extract from source
Also here you see that separing prg and c will be more useful for
generating documentation
Yes. Same goes for every tool which makes a decision
about the
There is also a workaround where you #include external
.c code inside BEGINDUMP/ENDDUMP. So that you can switch
between both methods. This adds some more complexity,
though.
He cannot. As I said in xHarbour this feature does not work
correctly and #include ".c" inside BEGINDUMP/ENDDUMP
is yet an
loper List.'
Subject: R: R: R: [Harbour] HB_STATIC_FUNC
Hi Victor,
> From a purely practical POV regarding hwgui, the only
> thing I don't see here is what makes ANIMATE
> class so different from the other classes, that this
> problem is present here, but not in other places.
On Fri, 06 Jun 2008, Szakáts Viktor wrote:
Hi Viktor,
> There is also a workaround where you #include external
> .c code inside BEGINDUMP/ENDDUMP. So that you can switch
> between both methods. This adds some more complexity,
> though.
He cannot. As I said in xHarbour this feature does not work
Hi Maurizio,
Yes, of course, i could hide something that could be hidden natively.
If no solution will came i'll do so, or i'll use some #ifdef
__XHARBOUR__
taking decision at compile time about the scope of methods.
Not a problem at all.
There is also a workaround where you #include extern
Hi Victor,
> From a purely practical POV regarding hwgui, the only
> thing I don't see here is what makes ANIMATE
> class so different from the other classes, that this
> problem is present here, but not in other places.
>
Simply because this was first class in alphabetical order and when i sta
Hi Maurizio,
Notice that amongst the 7 files using "inline" C,
hanimat.prg is the only one actually using STATIC,
and all those functions have distinct global names
anyway, so IMO the whole problem is quite marginal
and academic.
Not so, IMHO.
The Bcc/xHarbour resolves the function reference
> -Messaggio originale-
> Da: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Per conto di
> Szakáts Viktor
> Inviato: venerdì 6 giugno 2008 9.40
> A: Harbour Project Main Developer List.
> Oggetto: Re: R: [Harbour] HB_STATIC_FUNC
> Notice that amongst the
Hi Maurizio,
I see that even in hwgui, there are plenty of .c and
.prg files anyway, so I wonder why the mixed ones?
One reason might be that this way, they can make
those C functions 'static' to the .prg file that uses
them (hence the recent question and all the hacking
to achieve this). To me
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
Hi Maurizio,
not at all.
My target is strong encapsulation of data and methods in class
implementation and i can obtain this, IMHO, only having in the same
source
the (x)harbour and C code. Otherwise the static function, i think
obviously,
will remain local to C module and cannot be reached
Hi Viktor,
> I see that even in hwgui, there are plenty of .c and
> .prg files anyway, so I wonder why the mixed ones?
>
> One reason might be that this way, they can make
> those C functions 'static' to the .prg file that uses
> them (hence the recent question and all the hacking
> to achieve t
Hi Massimo,
not at all.
My target is strong encapsulation of data and methods in class
implementation and i can obtain this, IMHO, only having in the same source
the (x)harbour and C code. Otherwise the static function, i think obviously,
will remain local to C module and cannot be reached by xBase
16 matches
Mail list logo
