From: Chris Vine <chris@cvine.freeserve.co.uk>
To: guile-user@gnu.org
Subject: Re: C++ Foreign Function Interface
Date: Mon, 14 Mar 2016 19:22:16 +0000 [thread overview]
Message-ID: <20160314192216.16464ddd@bother.homenet> (raw)
In-Reply-To: <87k2l559mf.fsf@gmail.com>
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
next prev parent reply other threads:[~2016-03-14 19:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-10 18:18 C++ Foreign Function Interface Arun Isaac
2016-03-10 21:17 ` Chris Vine
2016-03-11 17:09 ` Hans Åberg
2016-03-11 20:17 ` Arun Isaac
2016-03-11 22:40 ` Hans Åberg
2016-03-14 16:04 ` Arun Isaac
2016-03-14 19:22 ` Chris Vine [this message]
2016-03-14 21:12 ` Jan Wedekind
2016-03-11 23:36 ` David Pirotte
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160314192216.16464ddd@bother.homenet \
--to=chris@cvine.freeserve.co.uk \
--cc=guile-user@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).