C Function Declarations

["Antonio E. Scuri" <Antonio.Scuri@...>]

  Should we change our clean headers to include lots of defines to ensure 
better portability/compatibility ?

  Not every programmer is worried about that.

  So I am going to try to clarify some points. Although this is not 
related to Lua it self but the last few messages tell me that it is an 
important topic for the list and I think that many will be interested.

1) extern "C"

  If a library is implemented in C, all the headers that export functions 
must have the extern "C". This is no harmful, not against the ANSI C, and 
very useful to C++ developers.

  Lua is implemented in C, but have a special characteristic that compiles 
as C++ also. So, if we include the extern "C" and compile the library as 
C++, the exported functions will still have a C declaration. Since every 
C++ compiler supports this feature I think that Lua headers should contain 
the extern "C".

2) Calling Convention

  Some very specific tools does not use the C calling convention (i.e. 
arguments in the stack in the same order as the function declaration), 
instead they use the Standard calling convention (i.e. arguments in reverse 
order in the stack).

  Visual Basic and Delphi use the Standard calling convention to call 
functions implemented in C DLLs.

  For this to work, the most common way is to change the function 
declaration such as:

            void lua_open (void);

  to:

            void _stdcall lua_open (void);

  or

            void LUA_CALLCNV lua_open (void);

  As Lua is an embedded language, the usage within VB and Delphi is also 
an important topic. But the legibility of the header files decreases.

  And running a script to convert headers and source is not that bad.

  I do use many other external libraries and everyone of them have same 
small configuration steps.

  On the other hand some compilers can make all the functions in the 
library use the standard calling convention. I don't know if this works fine.

  But since this convention is used tougher with a DLL the solution 
depends on the DLL generation procedure.

3) Exporting Functions in Dynamic Libraries

  The creation of dynamic library is not a common sense among OSs and 
Compilers.

  In some of them, including Windows, you have to create a file with the 
list of the exported functions (.DEF in Windows). This is the most 
practical and simple way to do it.

  So if we have the script to change the source and headers of the 
exported functions to change the calling conventions, it is simple to 
create a script that builds a .DEF file for us.

  The other ways to build DLLs are not standard and depends on the 
compiler. But if you want to build C++ DLLs, exporting the class is the 
only practical way of doing it.

  Note: I think that "dllexport" is available only in Visual C++.

  On the other hand we have the very simple macro proposed:

       #define LUA_API_FUNCTION   extern __declspec(dllexport) [...]

  (Note: __declspec(dllexport) this is valid only for Visual C++ "6" )

  Well, this macro can also solve the problem of the stdcall.

  Putting all in the one bag and shaking it came out with a suggestion, 
add the LUA_API_FUNCTION macro just before every exported function 
declaration and definition. This will help changing the calling 
conventions, creating DLLs, building scripts for both cases, and more.

CONCLUSIONS of the suggestions:

   - Add the extern "C"
   - Add a macro LUA_API_FUNCTION just before every exported function 
declaration and definition

Best Regards,
Antonio Scuri