C++ Foreign Function Interface

C++ Foreign Function Interface

[Arun Isaac]

[-- Attachment #1: Type: text/plain, Size: 176 bytes --]

Hi,

Is there any foreign function interface for C++ shared libraries in
Guile? Can I somehow use the C FFI for this? Is there any documentation
for this?

Thanks,
Arun Isaac.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: C++ Foreign Function Interface

[Chris Vine]

On Thu, 10 Mar 2016 23:48:43 +0530
Arun Isaac <theroarofthedragon@gmail.com> wrote:
> Hi,
> 
> Is there any foreign function interface for C++ shared libraries in
> Guile? Can I somehow use the C FFI for this? Is there any
> documentation for this?

If you want to link with a C++ library when using libguile (and, say,
want to make functions in the library accessible to scheme code using
scm_c_define_gsubr()), then you need to declare interface functions as
extern "C" so they have C language linkage.  That will amongst other
things suppress name mangling and make sure the correct calling
convention is used.  The same applies if you are planning to use, say,
pointer->procedure.

Chris

Re: C++ Foreign Function Interface

[Hans Åberg]

> On 10 Mar 2016, at 19:18, Arun Isaac <theroarofthedragon@gmail.com> wrote:

> Is there any foreign function interface for C++ shared libraries in
> Guile? Can I somehow use the C FFI for this? Is there any documentation
> for this?

You will have to write it yourself. It has been discussed before on this list [1]. I wrote a sample [2], though, Guile, being dynamically typed, does not have a C++ distinction statically typed between integers and rational numbers.


1. https://lists.gnu.org/archive/html/guile-user/2015-01/msg00016.html

2. https://secure2.storegate.com/Shares/Home.aspx?ShareID=56659ce2-127e-455e-ba1f-e6cbc82ba973

Re: C++ Foreign Function Interface

[Arun Isaac]

[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]


Chris Vine <chris@cvine.freeserve.co.uk> writes:

> If you want to link with a C++ library when using libguile (and, say,
> want to make functions in the library accessible to scheme code using
> scm_c_define_gsubr()), then you need to declare interface functions as
> extern "C" so they have C language linkage.  That will amongst other
> things suppress name mangling and make sure the correct calling
> convention is used.  The same applies if you are planning to use, say,
> pointer->procedure.

I'm trying to use the GNU Radio library (written in C++) from scheme.
While I can't really modify the library itself, I can wrap functions I
need in C, and then call them using Guile's C FFI. I'll do that.

Hans Åberg <haberg-1@telia.com> writes:

> You will have to write it yourself. It has been discussed before on
> this list [1].

In one of the messages in the earlier thread, I found a link to
https://isocpp.org/wiki/faq/mixing-c-and-cpp

That page gives me some idea of how I can write C wrappers for my C++
library.


[-- Attachment #2.1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #2.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: C++ Foreign Function Interface

[Hans Åberg]

> On 11 Mar 2016, at 21:17, Arun Isaac <theroarofthedragon@gmail.com> wrote:
> 
> Hans Åberg <haberg-1@telia.com> writes:
> 
>> You will have to write it yourself. It has been discussed before on
>> this list [1].
> 
> In one of the messages in the earlier thread, I found a link to
> https://isocpp.org/wiki/faq/mixing-c-and-cpp
> 
> That page gives me some idea of how I can write C wrappers for my C++
> library.

When calling C++ from C, you can’t pass a C++ exception through the C code. So in my example code, there are conversions between C++ and Guile exceptions.

Re: C++ Foreign Function Interface

[Arun Isaac]

[-- Attachment #1: Type: text/plain, Size: 651 bytes --]

Hans Åberg <haberg-1@telia.com> writes:

> When calling C++ from C, you can’t pass a C++ exception through the C
> code. So in my example code, there are conversions between C++ and
> Guile exceptions.

Yeah, this was the discussion in the other thread you linked
to. Unfortunately, I don't know anything about C++ exceptions, and hence
didn't understand what your code was doing. Can any of this be
integrated into guile itself, so that C++ FFI will be easier for the end
programmer?

David Pirotte <david@altosw.be> writes:

> May be this will interest you:
> 	https://github.com/BSeppke/vigra_c/

This is useful too. Thanks!


[-- Attachment #2.1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #2.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: C++ Foreign Function Interface

[Chris Vine]

On Mon, 14 Mar 2016 21:34:24 +0530
Arun Isaac <theroarofthedragon@gmail.com> wrote:
> Hans Åberg <haberg-1@telia.com> writes:
> 
> > When calling C++ from C, you can’t pass a C++ exception through the
> > C code. So in my example code, there are conversions between C++ and
> > Guile exceptions.  
> 
> Yeah, this was the discussion in the other thread you linked
> to. Unfortunately, I don't know anything about C++ exceptions, and
> hence didn't understand what your code was doing. Can any of this be
> integrated into guile itself, so that C++ FFI will be easier for the
> end programmer?

I am not a guile developer but I doubt (as a C++ programmer) that that
is worth the effort.  If you are calling into a C++ library from any C
code then you need to consider what exceptions the library might
throw.  Your 'extern "C"' interface then needs to catch these
exceptions and turn them into something else.  That might mean
providing a return value indicating an error condition, or if you are
programming in guile mode with libguile at that point might mean
throwing a guile exception.  You can probably ignore std::bad_alloc.
On most modern systems that exception will not be thrown (you will just
thrash), and when you are out of memory there is nothing you can do to
recover anyway as the kernel will take over.  The overall point is that
you need to ensure that, if you are in guile mode, any C++ exceptions
are handled locally and do not escape out of a guile dynamic extent nor
out of a function with C calling convention.

You also need to be aware of the converse, namely that if you throw a
guile exception out of C++ code, there are no C++ objects with
non-trivial destructors in scope when the guile exception is thrown, or
you will get undefined behaviour: most probably the destructors of the
C++ objects will not be called.  A guile exception is basically a long
jump up the stack.  But that is almost certainly not an issue if all
you are doing is calling into a C++ library when in guile mode.  It
will be an issue if you are yourself constructing your own C++ objects
when in guile mode.

In most cases this is pretty easy to accomplish once you get the hang
of it.

Chris

Re: C++ Foreign Function Interface

[Jan Wedekind]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2854 bytes --]

On Mon, 14 Mar 2016, Chris Vine wrote:
> On Mon, 14 Mar 2016 21:34:24 +0530
> Arun Isaac <theroarofthedragon@gmail.com> wrote:
>> Hans Åberg <haberg-1@telia.com> writes:
>>
>>> When calling C++ from C, you can’t pass a C++ exception through the
>>> C code. So in my example code, there are conversions between C++ and
>>> Guile exceptions.
>>
>> Yeah, this was the discussion in the other thread you linked
>> to. Unfortunately, I don't know anything about C++ exceptions, and
>> hence didn't understand what your code was doing. Can any of this be
>> integrated into guile itself, so that C++ FFI will be easier for the
>> end programmer?
>
> I am not a guile developer but I doubt (as a C++ programmer) that that
> is worth the effort.  If you are calling into a C++ library from any C
> code then you need to consider what exceptions the library might
> throw.  Your 'extern "C"' interface then needs to catch these
> exceptions and turn them into something else.  That might mean
> providing a return value indicating an error condition, or if you are
> programming in guile mode with libguile at that point might mean
> throwing a guile exception.  You can probably ignore std::bad_alloc.
> On most modern systems that exception will not be thrown (you will just
> thrash), and when you are out of memory there is nothing you can do to
> recover anyway as the kernel will take over.  The overall point is that
> you need to ensure that, if you are in guile mode, any C++ exceptions
> are handled locally and do not escape out of a guile dynamic extent nor
> out of a function with C calling convention.
>
> You also need to be aware of the converse, namely that if you throw a
> guile exception out of C++ code, there are no C++ objects with
> non-trivial destructors in scope when the guile exception is thrown, or
> you will get undefined behaviour: most probably the destructors of the
> C++ objects will not be called.  A guile exception is basically a long
> jump up the stack.  But that is almost certainly not an issue if all
> you are doing is calling into a C++ library when in guile mode.  It
> will be an issue if you are yourself constructing your own C++ objects
> when in guile mode.
>
> In most cases this is pretty easy to accomplish once you get the hang
> of it.
>
> Chris
>

It might be worth having a look at Christian Schafmeister's CLASP [1,2]. 
There is no standard C++ binary ABI (application binary interface). CLASP 
basically is a Lisp with an interface to LLVM C++ binaries.
I think in general it will be necessary to parse the C++ headers in order 
to interface with the C++ binaries (e.g. virtual method tables, member 
variables, functions declared in header files).

Jan

[1] https://github.com/drmeister/clasp
[2] https://www.youtube.com/watch?v=8X69_42Mj-g

Re: C++ Foreign Function Interface

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 573 bytes --]

Hello,

> In one of the messages in the earlier thread, I found a link to
> https://isocpp.org/wiki/faq/mixing-c-and-cpp

May be this will interest you:

	https://github.com/BSeppke/vigra_c/

Here is a link for a pdf which is a presentation about using the above from Common
Lisp...:

	https://duckduckgo.com/l/?kh=-1&uddg=https%3A%2F%2Fkogs-www.informatik.uni-hamburg.de%2F~seppke%2Fcontent%2Fresearch%2Fpublications%2F2010_seppkeetal_els.pdf

There used to be a similar project/approach by the OpenCV folks as well, I
think, not sure...

Cheers,
David

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]