[plt-scheme] C++ Bindings using FFI
> 1. The SWIG code that you sent doesn't do anything with the Scheme
> foreign interface.
>
Indeed, you are right. What I sent was what I need to feed SWIG *at this
moment*.
SWIG will parse these things, and generate C glue code from it.
I'm personally not using C++ header files. But swig can parse C++
classes, and
the generating backend will generate C glue code.
''If you want to use SWIG with the FFI, you will need to write a
generator that
generates FFI scheme code''.
> 2. It won't help you deal with the difficulties of interfacing C++
> libraries.
>
Indeed. It won't solve the name mangling stuff for the FFI.
==> There's years of development time in SWIG. It parses stuff very well.
I would try to integrate an FFI backend into SWIG. Only the developers need
SWIG after that. Users can just rely on the FFI code.
Again. SWIG is only needed for the parsing and generation part. You don't
need to distribute SWIG with your code.
> In any case -- yes, it's a good idea to use SWIG to generate the
> Scheme interface description -- and it would even be better to do it
> in Scheme, given a C header parser. (Joe Marshall had a working
> parser if anyone's interested in taking that.) In any case, you can
> either approach this dynamically and create the interface at run-time,
> or statically and distribute a pre-made interface.
>
> SWIG will work for a pre-made interface, as a number of other
> approaches, including parsing header files, or the SGL approach of
> compiling and running a small C file that spits out the required
> information (mostly integer sizes). The problem is that all of these
> require you to distribute a fixed interface, which might break on user
> machines that have different setups.
>
> The dynamic approach is much better, but things become more difficult
> -- you probably won't have SWIG on the user machine, possibly not even
> GCC. Even if you can parse header files, you may not have them...
> There's no simple way around this without the required
> meta-information... It's the basic problem of living in a world of
> meta-information-less C libraries.
>
> There are some libraries, like ImageMagick, that are really good for
> foreign interfaces. In the ImageMagick case, the library can have a
> different-sized integer as the basic type that is used -- and you get
> a function in the interface that returns this size, which makes it
> easy to bind it dynamically.
>
>