On Wed, 09 Dec 2009, Mindaugas Kavaliauskas wrote:
Hi,
> Przemysław Czerpak wrote:
> >>Perhaps copy-paste from some of my contrib RDDS. BTW, why RDD has
> >>this in symbol table?
> >It's necessary for *_GETFUNCTABLE function which is accessed from
> >hb_rddRegister() by global symbol table.
> Yes, but this answers why f.e. DBFCDX_GETFUNCTABLE is included into
> symbol table in dbfcdx1.c. But why DBFCDX is also in symbol table? I
> can not find any usage of this symbol in hb_rddRegister().
There are no technical reasons to register it.
I can only guess that at the beginning when someone created code to register
<RDDNAME>_GETFUNCTABLE() then he also added <RDDNAME>() to the symbol table
and so far we are using the same method.
The exception is only RDDADS library where only one of ADS* RDDs can be
requested but all are available so it's good to register all symbols to
make type( cRddName+"()" ) working for all available RDDs not only the
one which was explicitly REQUESTed.
> Do you think it will be a good practice to add a define like:
> #define HB_CAIRO_REQUEST_EXTERN
> #include "hbcairo.ch"
> and put request for all library functions into hbcairo.ch inside ifdef?
> Define name can have another structure is this is not suitable:
> HB_CAIRO_EXTERN, HB_CAIRO_REQUEST_LIBRARY, HB_EXTERN_CAIRO, etc.
Probably HB_CAIRO_EXTERN and HB_CAIRO_DYNAMIC so in the header file
we can make:
#undef HB_CAIRO_REF
#if defined( HB_CAIRO_DYNAMIC )
#define HB_CAIRO_REF EXTERN
#elif defined( HB_CAIRO_EXTERN )
#define HB_CAIRO_REF DYNAMIC
#endif
#ifdef HB_CAIRO_REF
HB_CAIRO_REF <func1>
HB_CAIRO_REF <func2>
[...]
HB_CAIRO_REF <funcN>
#endif
and use one list for DYNAMIC and EXTERN declaration.
For sure it can be usable but such list have to be synced with library
code so it's some additional job. It will be also more flexible to keep
them in separated files without any other definitions for 2 main reasons:
1. it's much easier to write helper tool creating automatically file with
such list from scratch then tool updating existing file which contains
also other definitions and PP directives. In the future we may try to
create such tool for few compilers, i.e. I wrote sth like that for
my own use as few lines shell script which creates such list for GCC
libraries using 'nm'.
2. in some cases different libraries can use incompatible preporcessor
directives so their header files cannot be mixed but programmer may
need to include extern function declaration for both libraries to
create final binaries which will have references to all functions.
Keeping function lists in separated files without any other PP
directives which may cause collisions resolves the problem.
best regards,
Przemek
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
