[plt-scheme] C++ Bindings using FFI

On 08/05/06, Hans Oesterholt-Dijkema <hdnews at gawab.com> wrote:
>
> > IIUC, it does not generate the code from scratch -- for example, when
> > you write:
> >
> >   %typemap(in) T * {
> >     mzgtk2_catch(SCHEME_LISTP($input),TYPENAME);
> >     $1=NULL;
> >     {
> >       int i,N=scheme_list_length($input);
> >       Scheme_Object *obj,*list=$input;
> >       for(i=0;i<N;i++) {
> >         obj=scheme_car(list);
> >         list=scheme_cdr(list);
> >         mzgtk2_catch(PREP(obj),TYPENAME);
> >         $1=GTKCALL(g_list_append,($1,MZ_C(obj)));
> >       }
> >     }
> >   }
> >
> > it looks like a bunch of code that it will send to GCC.
> >
> True. But note that this little file with 628 lines of type mappings is
> the only one I need to
> generate all code that is needed from the 21.000 lines of Gtk+ headers.
>
> I imagine there would also be typemap code needed for the FFI, but maybe
> much simpler.
>
> > (Using SWIG to generate Scheme glue code means that you only use its
> > parsing ability.)
> >
> No. Not really. You need to write a scheme generator. Weather you write
> a C generator or
> a Scheme generator doesn't really matter, or does it?
> >> Again. SWIG is only needed for the parsing and generation part. You
> >> don't need to distribute SWIG with your code.
> >>
> >
> > Yes, I'm aware of that.  The point I made is different: say that you
> > write an interface for `libfoo', which provides a `foo' int->int
> > function -- SWIG knows about this from the header file and will
> > generate the Scheme glue code.  Later on I download your code, but I
> > have an older version of libfoo, where `foo' is char->char.  (More
> > than that -- I might not have the libfoo header files.)
> >
> >
> Users never need the libfoo header files. Because the swig code has been
> already generated.
>
> So, maybe I'm missing a link here. Does the FFI know from the library,
> how a function is typed?
>
>

I've never used SWIG so this comment might be biased and brutally wrong.
As far as I have understood libffi opens the library in scheme, reads
the file and lets you in Scheme create bindings accessing its
internals, so it seems to have a dynamic access to the library, if the
library changes, the bindings change with it.
In Swig, the header info given by the typemaps are passed to swig
which parses the headers or whatever and generates the C code for
mzscheme to generate the bindings for the library, which means that if
the lib changes you have to rerun swig on the headers and typemaps to
have new bindings, so it generates 'static bindings' in comparison
with libffi.

At first I would think that libffi would be the way to go. I see no
reason for using swig now with libffi available.

As I said, this can probably be just non-sense.

Paulo Matos

> --Hans
>
>


--
Paulo Jorge Matos - pocm at sat inesc-id pt
Web: http://sat.inesc-id.pt/~pocm
Computer and Software Engineering
INESC-ID - SAT Group