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 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. > 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. Best regards. Maurizio _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
