On Fri, 06 Jun 2008, Alex Strickland wrote:
Hi Alex,
> > DECLARE [STATIC] FUNCTION [()]
> >or:
> > PROTOTYPE [STATIC] FUNCTION [()]
> >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 lik
Szakáts Viktor wrote:
I vote against to add yet another language element
to support a concept bleeding from several wounds.
I would agree with you if Przemek did not imply that it would be a
beneficial side effect of a strong typing implementation.
Regards
Alex
_
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
I vote against to add yet another language element
to support a concept bleeding from several wounds.
We'd just open a door for more future problems IMO.
In relation to hwgui, I doubt this issue is a real
showstopper to make it happen.
Brgds,
Viktor
On 2008.06.06., at 12:28, Alex Strickland wr
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
Przemyslaw Czerpak wrote:
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 dumpe
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
ragma begindump
>
>#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-
>
:171:HB_FUNC ( TRACKBARSETRANGE )
printdos.prg:615:HB_FUNC( AFILLTEXT )
Brgds,
Viktor
Best regards.
Maurizio
-Messaggio originale-
Da: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Per conto di
Massimo Belgrano
Inviato: giovedì 5 giugno 2008 23.54
A: Harbour Project Main Developer List.
Ogg
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
ale-
> Da: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Per conto di
> Massimo Belgrano
> Inviato: giovedì 5 giugno 2008 23.54
> A: Harbour Project Main Developer List.
> Oggetto: RE: [Harbour] HB_STATIC_FUNC
>
> Hi Maurizio
> Your problem in hwgui will be reso
lf Of Szakáts Viktor
Sent: Thursday, June 05, 2008 7:46 PM
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] HB_STATIC_FUNC
I'd add one more problem with INLINE C code:
I extensively use grep for Harbour and my own projects
too, it's a very powerful tool to locate stuff in
Hi Maurizio
Your problem in hwgui will be resolved isolating c code in external *.C ?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Szakáts Viktor
Sent: Thursday, June 05, 2008 7:46 PM
To: Harbour Project Main Developer List.
Subject: Re: [Harbour
Nonsense and a waste of time. ("Fából vaskarika" in Hungarian)
Hi Przemek,
I'm not sure you understood.
We will need such prototyping for strong type checking in .prg code.
Probably the side effect of this will be also addressing the issue
with functions declared inside #pragma begindump. If
On Thu, 05 Jun 2008, Szakáts Viktor wrote:
Hi Viktor,
> > PROTOTYPE [STATIC] FUNCTION [()]
> >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 e
I'd add one more problem with INLINE C code:
I extensively use grep for Harbour and my own projects
too, it's a very powerful tool to locate stuff in the
source.
When I'm looking for C code parts (function names
let's say), naturally I search through *.c files only.
Problem: C code may be hiding
Hi Przemek,
PROTOTYPE [STATIC] FUNCTION [()]
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.
Nonsense and
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_EX
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.
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.
Maybe
28 matches
Mail list logo
