Library Design
Moon2
when designing a library, any links or comments will be greatly appreciated.
Thanks
Ed Mulroy
Do you mean a dynamic linked library, a *.DLL or a static library, a *.LIB?
Is it to be C or C++?
If C++ is it meant to be able to be used with the same compiler or to also
be usable with other company's compilers?
. Ed
> Moon2 wrote in message
> news:4596...@newsgroups.borland.com...
Moon2
"Ed Mulroy" <dont_e...@bitbuc.ket> wrote in message
news:45973b76$1...@newsgroups.borland.com...
Ed Mulroy
binary. If source there are few constraints but as binary other issues come
into play.
Assuming binary:
There are three major issues, naming of public variables, memory
organization and runtime library functions.
Public names are names associated with items in the source code. Each has a
public name or name as used by the linker which is not necessarily the same
as the name as seen in the source code. These names vary depending upon
which compiler and whoat calling convention was used.
Memory organization will vary across classes and in structures where the
class or structure inherits or has functions or uses templates.
Runtime library issues arise when a function or variable supplied by one
compiler's runtime library is not available in the runtime library of the
compiler used by the customer. This does not appear to be an issue when
dealing with functions that are required by the language standard for C or
C++. Note that some non-standard variables are found in all. For example,
all compilers for Windows that I have seen create and initialize this
variable for the instance handle of the executable or DLL.
extern HINSTANCE _hInstance;
The manner in which public C++ function and class member symbols are formed
and the internal memory layout of classes varies across compilers.
Therefore one must arrange for the public symbols used by the using code are
formed and usable in a manner which is common to them all.
That is done by providing standalone functions to access items in the
library. Those functions should be decorated with extern "C" and use the
__stdcall calling convention. The macro WINAPI is often seen decorating
functions. It expands to __stdcall. Note that, with the exception of
wsprintf and wnsprintf, that is used by all the WIN32 API functions.
For example:
// start of header file
#ifdef __cplusplus
extern "C" {
#endif
int WINAPI FuncName( --arg list--);
// other items
#ifdef __cplusplus
}
#endif
// end of header file
The macro __cplusplus is required by the C++ language spec to be defined
during C++ compilation. Using the #ifdef--#endif block around it makes C
code able to use this same header file because it will not see the extern
"C" line.
In the source code those items mentioned in the header file must also be
decorated by extern "C" and given as WINAPI or __stdcall.
For classes that are not totally defined in the header file are used,
functions are provided to handle them.
Classes totally defined in the header file are those whose code and data are
provided as inline in the header so have no code in the library. If
inheritance is used then all classes from which they inherit must also be in
header files for them to be totally defined.
In general simple global variables will be usable across compilers without
any special decorations. For example:
In the header file:
extern int some_variable[];
In one source file of the library:
int some_variable[22];
I hope this helps.
. Ed
> Moon2 wrote in message
> news:4597...@newsgroups.borland.com...
Ed Mulroy
Library files and object files for Windows compilers seem to come in two
forms, the way Microsoft now does them and the way Borland does them (which
is how Microsoft used to do them).
If creating a library to be used by your customers, it would be best to
create it twice, once with the Borland compiler and once with the Microsoft
compiler.
. Ed
> Moon2 wrote in message
> news:4597...@newsgroups.borland.com...