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 this seems like something
which can be resolved using some internal namespaces,
or other logical distinction between published and
private API. All in all this is a fully regular problem,
present in all projects using more than one source
file, and everyone solves it without mixing.
IMHO, i think that the solutions obtained without mixing prg and c
code have
as side effect that the function declared as static have still
public scope
and thus reachable by other modules of application.
I see your problem, but I'd solve it differently.
Also see my other mail.
BTW, hwgui main source folder has two hb_inline()s,
both seems easy to replace with one hb_bit*() call
each, plus there are a few files with BEGINDUMP, no
C code there has any special properties (and only some
of them are 'static') which would prevent moving them
into .c files, IMO. I had similar experience when porting
code with inline C from xhb to Harbour.
In the hwgui CVS repository you can find source/hanimat.prg and take
a look
to what i'm meaning. This code works in xHarbour but in Harbour
(stable
version) don't resolves the HB_STATIC_FUNC correctly giving error at
compile
time. Avoiding the STATIC, the functions, also if present in the prg
file,
obviously become freely callable by other modules, and this is what
i would
to avoid.
I think, after all, this is a real problem when is needed some C
implementation AND encapsulation of class or standalone functions.
IMO the concept of C encapsulation is wrong several ways, and
while I can imagine a few situation where it can makes some
sense (like what you say), the downsides are so numerous that
I think this is something better to solve the "regular" way.
And again - staying in the scope of hwgui - hanimat.prg is the
only .prg with this proplem so I think it would be much more
easy to solve it there, than start building a C preprocessor
inside Harbour (too?). We're in fact going into the opposite
direction regarding inline C here. Had this be solved, hwgui
may work with Harbour too, which would be a great thing.
Brgds,
Viktor
PS: BTW, the other not-too-welcome feature is .asm usage
in .c code (and also in Harbour in general). We have one such
file in Harbour repo (contrib/hbwhat32/_wincall.c) and this
causes it to not compile for BCC55 users. It would be nice
if this DynaCall() function could be modified to be pure C.
Pritpal, if you read this :)
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
