🚀 go-pugleaf

I should have also asked if the library is to be provided as source or as 
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:45977b0c@newsgroups.borland.com...
>
> Static library, for different compilers.