Hi Przemek,
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.
Nonsense and a waste of time. ("Fából vaskarika" in Hungarian)
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.
I cannot agree more.
I see we have -ki (hb_inline) enabled by default.
Can't we make this disabled in next version (or even
current one)? Also I think we'd need another switch to
disable BEGINDUMP/ENDDUMP. It's happened several time
that I've spent time looking around for C stuff, and
at the end I had to realize that it's inline C code.
Quite a waste of time. Not to mention the numerous
non-portable code you mention.
It can be very rarely useful if I want to quickly
test a small program needs C code (using bld.bat),
but I'd perfectly be happy to use a Harbour switch
to enable the feature in these few cases.
As for hb_inline() I'd remove it completely.
Shall we go in this direction?
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour