Re: Development/Production versions (was RE: CVS)

[Reini Urban <rurban@x-ray.at>]

Noel Welsh wrote:
> > Is the distinction important to the people who want to use a glue
> > generator?
> 
> As I understand it, the most important difference is that SWIG allows
> one to connect to C++ code, whereas Eli's method will only allow calls
> to C shared objects (or C++ shared objects if you know the name
> mangling scheme in use, which I certainly don't). Eli's method is a
> great solution for C libraries, but falls down for 1) things that
> aren't libraries and 2) C++ code; which is where SWIG is handy.

ad 2) "C++ code":
I wouldn't see the various name mangling schemes a major hindrance for 
a C++ FFI.

First, if you have the sources you could generate a def file with all 
exported functions and either call these weird names then or otherwise 
enum or alias them if you don't like the mangling scheme. 
recompile with your new numbers or aliases and it is under your control.

secondly, if you have only the binary you can look into the 
exports section and also export a def file automatically.
but then you'll have to stay with the mangled names.
most compilers also have a demangler, if you really don't know for 
what kind of parameters this method is for.

In my AutoLISP FFI I only call C++ functions (from AutoCAD) from a set 
of ~5000. By name it is sligthly portable (it changed from msvc5 to 6), 
by enum also quite portable (newer funcs should go behind but they rarely do), 
of course by alias it always work.

ad 1) "things that aren't libraries":
A FFI to an external process (an EXE) is my next research topic. 
It really should be doable somehow. The AIX dynaloading scheme is a good 
starting point, examining the exe header for exports and scanning these.
I actually know some people which call and even hook functions in EXE's which 
are not exported. This is an commercial app.
-- 
Reini Urban    
http://xarch.tu-graz.ac.at/autocad/lisp/ffis.html